Not my favorite job. Learn to do a proper database design; it's not that hard. Balance denormalization against querying needs (disk space is cheap). Use json serialized objects to your advantage for complex things that you don't actually query on. The price you pay for adding complexity to a database is query time overhead, joins, and the resulting application level complexity, bugs, and overhead. You'll need lots of columns with indices to support all that. The queries get more complex and expensive. Etc. Needless complexity at the database level is not a good thing. Keep it simple.
Mostly, you don't need your database model to resemble your domain model. You just need it to store it. A simple database model could be a table with a key and a json blob. Perfectly valid for a lot of domain models. And databases like postgres support creating indices on things inside your json. So, you don't even lose the ability to query. If you really need extra columns (e.g. a timestamp), add them of course.
The mistake that people make is assuming that all the little objects in their domain are equally important. They are not. Most of it is just meta data that needs to be attached to something that is never/rarely used for querying. It needs to live somewhere. But that doesn't necessarily have to be a dedicated column or table in a database.