Domain-Driven Design – How to Persist an Aggregate Containing Polymorphism

Yes, you can call repositories from within entities. But should you do it? Probably not, it often gives you more technical problems that it will benefit you, it also has the risk of making performance tuning very difficult (mostly because it invites bad design).

The validation example also does not seem to justify calling repositories from your entities. Also your example seems to imply that your object can exist in an invalid state, this should be avoided, your domain object should always be in a valid state.

Validation should already start at domain object creation time. If the creation logic is simple, you can keep this kind of logic in the objects constructor. But still the creation logic is kind of separate from the rest of the logic as it’s only needed during creation time and not during the rest of the lifecycle of an object. Thus when creation logic gets complex enough, like calling repositories, you should spinoff this separate concern to another object, a factory object.

You clarified that you use frontend technology that creates objects for you. In that case, I would say that those object are just application value objects that can be used for input to your object factories (or constructors for that matter). Application validation of the fields though, should probably stay separate from your domain though.

In general you should try to avoid giving domain objects setters for all properties. Instead you should provide domain actions on the object. Thus instead of having a method like: setOrderStatus(Order.PROCESSED) you should have a method processOrder(). This way each method will always result in a valid state (or else throw an exception). Note that I write in general, as for trivial fields that have no connection to domain logic and are just representing data, you can still use setters.

For simple data centric applications this kind of approach might give too much overhead though. But then again, that’s not where DDD is meant to be used.

The blue book is definitely worth a read if you want to get the best out of the DDD approach. DDD patterns are not trivial and learning the essence of each of them will help you ponder when to use which pattern, how to divide your application in layers, how to define your Aggregates, and so on.

The group of 2 entities you're mentioning isn't a Bounded Context - it's probably an Aggregate. Each Aggregate has an Aggregate Root, an Entity that serves as a single entry point to the Aggregate for all other objects. So no direct relation between an Entity and another Entity in another Aggregate that is not the Aggregate Root.

Repositories are needed to get hold of Entities that are not easily obtained by traversal of other objects. Repositories usually contain Aggregate Roots, but there can be Repositories of regular Entities as well.

In your example, Conversation seems to be the Aggregate Root. Maybe Conversations are the starting point of your application, or maybe you want to query them with detailed criteria so they are not satisfyingly accessible through simple traversal of other objects. In such a case you can create a Repository for them that will give the client code the illusion of a set of in-memory Conversations to query from, add to or delete from directly. Messages on the other hand are easily obtained by traversal of a Conversation, and you might not want to get them according to detailed criteria, just all of a Conversation's Messages at once, so they might not need a Repository.

ConversationRepository will play a role in persisting Messages, but not such a direct role as you mention. So, no AddMessage() on ConversationRepository (that method rather belongs in Conversation itself) but instead, each time the Repository will persist a Conversation, it's a good idea to persist its Messages at the same time, either transparently if you use an ORM framework such as (N)Hibernate, using ad hoc SQL if you choose so, etc.