A question about DDD, 5-tier model and business logic [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

As I get it, the model in is DDD divided into these tiers:

• Storage (database, file, cache ...)
• Mapper (takes data from the storage)
• Repository (manages data for a single entity type, can use different mappers)
• Entity (a simple data container, independent of other tiers)
• Service (handles business logic like Get the 5 newest posts ordered alphabetically by title, uses the Repository)

So, this is are the 5 tiers (please correct me if I misunderstood something). And the question is:

If I have business logic that is related to a single entity, should I implement it in the Entity, or in the Service?

For example, if I have a post and want to retrieve all its comments that are approved, should it be Post.getApprovedComments (entity) or CommentsService.getApprovedCommentsForPost(Post post)?

(No, it's开发者_开发问答 not right to use post.getComments().filter(comment -> comment.approved), because that moves business logic out of the Model. Just in case someone asks.)

---

So, this is are the 5 tiers (please correct me if I misunderstood something).

I think often people will group Data Storage, ORM and the Repository in one 'layer' as far as your code is concerned. Also, don't forget about presentation.

If I have business logic that is related to a single entity, should I implement it in the Entity, or in the Service?

Yes, if it is behavior related to the entity then it should reside within the Entity. Entities shouldn't just be simple data containers, rather the Entity/Model layer should encapsulate both data-structure and behavior related to your business model. In this way, if you need to reuse the Model layer in another app, you dont have to dig around to find the related behavior that you stuck in other layers.

For example, if I have a post and want to retrieve all its comments that are approved, > should it be Post.getApprovedComments (entity) or > CommentsService.getApprovedCommentsForPost(Post post)?

Difficult to say without knowing more about your architecture and ORM. I'd probably go with the Post.. route (comments should be a collection on the Post entity), and then getApprovedComments could be a simple linq query or such. The Service based approach you suggest doesn't look very OOP to me.

(No, it's not right to use post.getComments().filter(c -> comment.approved), because that moves business logic out of the Model. Just in case someone asks.)

I'm not entirely sure I agree with you here. For something this simple, some might think it acceptable.

I'd add that:

Service (handles business logic like Get the 5 newest posts ordered alphabetically by title, uses the Repository)

...is in my opinion not a good example of a service. The service layer is doing nothing in this example - this should just be a query method defined in the PostRepository.

Hope some of that helps a little...