1

Apologies in advance if this question has already been answered, but I haven't been able to find a definition for what model actually means in this context that I actually grok.

I've heard the term model be used to describe just the persistence layer, all domain specific code, or just domain entities. From what I've read, anemic domain models seem to be regarded as a bad thing, but the specific reasons as to why don't quite seem to click with me and I think it's because I don't know what model is referring to in this context. US this specific to MVC?

If it's just referring to entities, what is the issue with only putting the logic to keep data integrity in the entities and the putting the logic for actually utilizing those entities into service classes? Is that still considered anemic? If that is the case how can you actually implement rich domain models without breaking single responsibility principle.

The answer doesn't need to be framework or language specific, but if it matters I'm working with php and Symfony2.

Thanks in advance anybody who takes the time to provide me some clarity!

echochamber
  • 1,835
  • 1
  • 15
  • 18
  • you mean like this: http://stackoverflow.com/a/5864000/727208 ? – tereško May 28 '14 at 05:17
  • Hi @teresko. Yes that is a great answer to most of my questions, Thank you. The part I am still fuzzy on is what is the distinction between a domain object and a service when following Domain Driven Design. What responsibilities fall to the services and what to the domain objects. – echochamber May 28 '14 at 05:46
  • 2
    Services deal with domain object to domain object and the domain object to persistence interaction (whether it's data mappers, repository or/and unit of work depends on your implementation). Domain objects handle the data validation and contain the business rules. – tereško May 28 '14 at 05:51
  • I just realized my misunderstanding was of what a "service" was in this context. I also noticed you're the same guy who's answered half my software architecture related questions.Thank you @teresko. You're definitely one of the best people I've come across in the php community. – echochamber May 28 '14 at 06:06
  • Domain services implement Domain _use cases_ while Domain entities and value objects implement concepts. – MikeSW May 28 '14 at 12:39
  • @MikeSW Just wanted to make sure I understand. So if I had had an ShoppingCart class and I wanted to get the net price of all items in a ShopingCart object, then that would belong in the Domain Entity? How about when a purchase was made for an item in the ShoppingCart? How about if I want to notify a person that an item in their cart has gone out of stock? Sorry for asking such a long question, I'm just trying to make sure I comprehend what qualifies as a use case. – echochamber May 28 '14 at 22:37
  • An use case it's a business process involving business concepts. A Domain service coordinates one of more concepts interactions in order to implement a business scenario. Create Invoice is a use case , Calculate tax is a use case etc. In a Domain you're modelling the concepts and their use cases as they happen in the business. Use cases can be implemented in entities (as part of another concept). A Domain Service implements the use cases which aren't part of a concept. Btw, notifying a client is more of an application service than domain's. – MikeSW May 28 '14 at 23:18

1 Answers1

2

Just on the distinction of what should be in the service layer versus the domain layer, here's a nice article by Martin Fowler on Anaemic Domain Models.

The anti-pattern he talks about is when the domain model lacks the domain logic & is really just a collection of getters & setters.

The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. The anemic domain model is really just a procedural style design.

Quoting Eric Evans, he says:

Application Layer [his name for Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems.

…

Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

[My emphasis]

Generally, his blog posts are a great introduction to some of the concepts within DDD.

anotherdave
  • 6,656
  • 4
  • 34
  • 65