Rich Domain Model and ORM

Question

Martin Fowler considers Anemic Domain Model as an anti-pattern.

Rolling the Persistence Model as the Domain Model seems severely off too due to Object Relational Impedence Missmatch. For persistence and normalization sakes, we tend to break down classes to very small tiny pieces, slapping methods on top of these classes is silly. Plus persistence rarely changes, but business logic changes a fair bit.

So we need a DomainModel that builds on the persistence model (instead of being one and the same). This Domain Model will then contains business logic properties and method.

But now these Domain Models are still behind the service, and in order to expose them out to the outside world we need to convert them over to DTOs.

We are doing so manny mappings here.

1. Persistence to Domain Model
2. To convert Domain Model into DTOs to pass along between services

It doesn't end there, since the DTO may need to be mapped into the ViewModel.

All that and the problem of duplicating validation logic still doesn't go away, because the client wants real time validation. ViewModel knows nothing about validation, so in an SPA for example, you're forced to rewrite the validation logic again, on the client side (usually in javascript).

Also services are by nature stateless (message or RPC oriented), so we're doing all these mapping, between Persistence, to OO then back to Procedural, to what benefit? How would you justify the cost in practical terms of most IT budget?

I get how having full DDD, with Aggregate Roots, Domain Models etc. would be "cool" but how can you justify the cost and the hit on dev productivity?

anti-pattern (or antipattern) is a pattern used in social or business operations or software engineering that may be commonly used but is ineffective and/or counterproductive in practice

And if so, wouldn't DDD and Rich Domain Model fit into the anti-pattern definition above than the "Lean" Domain Model. Sorry, I despise the loaded word, "Anemic".

By keeping the Domain Model, "Lean" you actually allow it to be shared without violating the "Abstract Dependency Principle", "Don't Repeat Yourself" and the time consuming, tedious and error prone process of mapping one data carrier to another, and whatever associated Unit Test that goes on top of that (unless you're thinking of doing mapping w/o unit testing and hope for the best).

Answer 1

It seems you're mixing up a lot of concepts, blaming the rich domain model approach for things it isn't directly responsible for.

• Rich domain model is orthogonal to layered architecture, especially having a rich domain model doesn't dictate the number of layers you have, what data structures should be exchanged between these layers and how they should be mapped.

• Rich domain model is orthogonal to validation and says nothing about the need for client-side checking in addition to back-end validation.

In other words, making your domain model anemic with all business logic in services won't necessarily save you from writing a lot of boilerplate DTO mapping code, nor will it remove the need for client-side "double checking" (which is by the way a commonly accepted best practice).

This doesn't mean your point about the cost and weight of a full-fledged multi-layered architecture isn't valid. You might find interest in this post by Mark Seemann discussing similar concerns : http://blog.ploeh.dk/2012/02/09/IsLayeringWorthTheMapping.aspx

Answer 2

tl;dr The domain model is not well defined, it's probably designed with a db centric approach in mind.

The main purposes of DDD is to model in code the Business concepts and processes. I really doubt that your business concepts and processes are just bags of properties. But if they really are then yes, the Domain Model can be the same as the Persistence Model so you don't have to do any mapping.

The persistence model models how object state is stored. If you're not in the domain of databases, then domain and persistence model can't have the same purpose. One of the biggest mistakes I see with DDD is thinking about the domain model like it's still data driven. In DDD you don't have a concrete database. You have repositories. There are no one-to-many, many-to-many etc relations. There are no tables and no rows. There are just objects which try to represent the Domain as accurate as possible.

Simply put, the Domain cares about modeling business behavior while the Persistence cares about storing object state. I see two different responsibilites here.

About validation, you have 2 types: validation of input data format and then validation of other business rules according to what you change in an object state.

About the duplication, I think you are referring to the input format but like @EbenRoux said there are mechanism which can help with that . In asp.net mvc most of those validation rules have the js version included as well.

Let me tell you a little secret with services. While their interface can be defined in the Domain, their implementation can sit in the Persistence Layer, thus allowing them to work directly with the storage. And since the rest of the app uses the service in their abstract form (the interface), only the DI Container will know the dirty secret.

DDD is not about being cool, it's about designing an application according to the domain. I'll bet few develop an app for the sole purpose to be an UI for the db. The majority aims to provide a service with their software,to build a virtual product which solves a problem. It makes sense that the design the app to be driven the problem you want solved and not by the technical tools you just happen to use.

How does this sound, you want a brick house but the constructor says:" Sorry but my saw only works with wood". Well, don't use a saw, use another tool wich can help cut a brick. The tools need to be adapted at the problem, not viceversa.