0

This question might seem strange, but it's something I've faced sometimes. I've been trying to adopt DDD, however I'm always facing the problem of anemic domain models. The problem is that when I start to think about what should be the behaviors of the domain objects, nothing comes to mind. I've started then to seek on the internet what should be put inside the behavior of the domain objects and many people say that are rules and validations.

The problem is that I've faced the situation many times where to customer who wants the system doesn't want any validation. Once I've asked a customer: "what are the required properties for this object?" and he said "no, I don't want anything like that, sometimes I want to just place one property and leave the others because I'm without time".

Then I've asked: "and what sould be the format of data for this property?" and he said "I don't want anything checked, I want to be free to put as I like". So the customer didn't want validation at all, so I coudln't implement it.

In that case, there's no validations, there are no rules in place. Then I've looked at the controllers (it was built with MVC) to see if there was any logic specific to the domain entities, and there wasn't any. Just logic to read and write data. So in cases like that, is it a problem to have anemic domain models?

Also, I'm working with .NET. In .NET we can put validation with Data Annotations, and we can write getters like properties. So methods to do validation when setting data aren't requireds, because the Data Annotations do the job, also methods to calculate data aren't required, because properties with just a special get can do the job. So what the behaviors become after all?

1 Answer 1

Reset to default
7

If the app has no business rules or business processes beyond CRUD, then there really is not behavior to capture in the domain. This is generally not the case in enterprise applications, but may be fairly common in simple web apps. DDD is really more focused on the former.

Thus the work for a CRUD-based web app will probably revolve around building a useful and usable UI. The back end should be pretty much a no-brainer.

3
  • Hi @MatthewFlynn, thanks for your answer. I really mainly create web apps, so it fits my situation. I just didn't understand one thing: why there's this difference between those two kinds of apps? It has to do with the stateless nature of web? If I work with SPA's and so pick MVVM libraries like KnockoutJS it changes this situation? Thanks for your attention.
    – user1620696
    Commented Jan 21, 2014 at 17:45
  • An enterprise app usually consists of several web apps. A bank, for instance, might have the ClientAccess webapp, the CsrAccess webapp, and a bunch of services to connect them to other banks. All of those comprise the "enterprise app". CsrAccess and ClientAccess will have common functionality, and the question is, where do you put it... DDD answers that question.
    – Jim Barrows
    Commented Jan 21, 2014 at 20:45
  • Not to completely contradict @JimBarrows, but in my experience, an enterprise application is an application that supports the running of an enterprise. I work in the health insurance business, so we have applications that, for example, manage the enrollment of new members or adjudication of claims. These encapsulate a lot of business logic--lots of things must happen when a new member submits her information--and so it becomes an interesting question as to how we divvy up the business rules and processes in the application. DDD is one approach to doing this.
    – Matthew Flynn
    Commented Jan 22, 2014 at 1:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.