Disclaimer: I'm not 100% sure I understand some of the practices and concepts in DDD, so this question may actually be answered by clarification of the ideasI'm working in a legacy system (written in PHP) in which the database tool provides no object relational mapping, and thus objects coming out of the database access layer tend to be, more or less, mirrors of the rows returned by the query.For newer modules, I'm trying to apply DDD. However, I'm struggling with how to build a rich domain model when my entities have no relations. Take for example the following requirement: users can see the messages they have previously accepted, where a message being accepted is, internally, recorded by a single new row in a database table. Were I using an ORM and did my entities have relations, I may write something akin to $user->getAcceptedMessages(), which would return a collection of message entities. However, since I don't have that, I'm torn between two approaches:Populate the relations as part of the building of the entity in the repository. The queries could get big, unwieldy and hard to maintain as the number of relations grows and the schema changes.Create services for actions such as this, which depend on the repository and a take a user, eg UserMessageAcceptanceService. However, I suspect this might lead to an anemic domain model.Is either approach sensible in this scenario? Or is some form of ORM a requirement for applying DDD effectively?
DDD with entities with no relations
object oriented design;domain driven design