I've been developing applications according to the principles of DDD for a while now, and, as many, I often run into issues when it comes to persisting an aggregate.One of the main advantages of DDD is that it allows me to use the full power of OO design in my domain -- as such I want to use polymorphism and conform to the open-closed principle.  I.e. I can extend my logic by adding new subtypes without requiring changes to the supertypes.The problem comes when persisting this.  Somehow I need to flatten this domain to some persisted representation, and then later restore it.  How do I achieve this, without littering the Repository implementation with instanceof (or equivalent in your language of preference) all over the place.  This is generally considered bad form, plus it violated OCP, at least in the repository itself.  When I add a new subtype, I'm forced to add a case in the repository.Is there an elegant way to handle this?
In DDD, how do I persist an aggregate containing polymorphism
domain driven design;open closed principle
One of the ways is to use reflection. During application startup, the repository would inspect structure of your domain entities and automagically determine relational model and mapping of entities to this relational model. This is basically what most modern ORMs can do. The disadvantage of this approach is that it is extremely complicated to implement for non-trivial cases and one small change in domain model might result in drastically different relational model, which complicates migrations between versions.Other than that, no, there is no way. If your repository depends on your domain model, it means the repository has to change when domain model changes. That is very definition of dependency. And OCP can only really work if things are not dependent of each other.But there is a way to make the change easier and safer. Why is usage of instanceof a problem? There is nothing wrong with using it. Its just that if you add new subtype, you don't know where you have to extend the code to support this new subtype. But there is solution for that : a Visitor pattern. With visitor, when you add a new subclass, you also add new method to an interface. This means every class that implements this interface will become non-compilable and you will immediatelly know where everywhere you have to extend the code to support the new class. Yes, it will make adding new subtype harder, but it will make that change safer.