Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Domain Model Overuse

I thought it was interesting to hear Eric Evans in a recent InfoQ interview say (emphasis mine):

I became more and more aware that one of the basic mistakes that model enthusiasts made from the start was the idea that we should just model everything, that the whole system should modeled and object oriented and so on. what I have started to realize is that that dilutes the effort to the point where we don’t really ever get the bang for the modeling buck and that in fact most systems are probably 90% CRUD (create, read, update, delete) and that there are simpler solutions to that problem

This is an excellent point. A good number of people are getting good bang for their buck from alternative (there’s that word again, damn) approaches like active record (SubSonic, Castle ActiveRecord, and Rails ActiveRecord to name a few).

Domain model, as a pattern, represents a significant technical risk and really shouldn’t be entered in to lightly. Look for areas where there is a lot of logic or complexity and maybe consider deploying it in a targeted fashion.

Still this doesn’t mean we need to throw the baby out with the bathwater. Patterns such as entity, service, and repository can almost universally benefit any application architecture, even very simple ones.

Inversely and in light of the ubiquity of entity and repository patterns, I think people often misapply the anemic domain model anti-pattern. It is only an anti-pattern when you see/smell/feel it in a complex problem. For the run of the mill, plain jane parts of our software it’s probably not the end of the world or even a problem. Active record or even table module is a fine choice for many simpler applications or even mixed in with models in a kind of dropstone architecture (where active record is the sediment and domain models are the dropstones). Do, say, a risk analysis domain model in an anemic fashion and you’re leaving a lot of value on the table in terms of encapsulating complexity, testability, and codebase organization. The anti-pattern fits there.

In our software we have a number of areas that are fairly simple but we still say they “live in the model layer.” Do they represent a full blown domain model? No. Do they live in the same layer as complex business logic? Yes. Do we employ the armada of DDD practices in the complex areas of our application? Well, we try to get better at applying them where they fit (where is key) every day.

This entry was posted in DDD, Domain Model. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

8 Responses to Domain Model Overuse

  1. Sorry. I mean the anemic domain model is an anti-pattern, but only if you are trying to implement a domain model. You can work with plain value containers and transactional scripts, that is just fine. Domain Models can be quite handy if you need to manage complex systems. The alternative is soft-coding or scattered logic in many different controllers. I guess the value of having a DDD grows as your project gets bigger.

  2. I do not consider the anemic domain model to be an anti-pattern at all… see my discussion :
    http://redbeanphp.com/about-redbean#anemicdomain

  3. Dave Laribee says:

    Nope.

    I think there’s a style that uses Entity, Repository, etc. that looks like Domain Model and you’d be tempted to say “hey that’s an anemic model” but it’s just fine to go that way…. especially when you are using Domain Model in other places.

    Not sure I articulated that fully.

  4. ET says:

    Sorry, but it looks you just really want to use AR and are trying to justify it in the face of DDD.

    Sure most apps are just CRUD and a real domain model is a drain. I think that’s all Eric was saying. Let’s not bring Anemic Model into it. Let’s just use RAD tools for those (which is what happens outside of Alt.NET anyways).

    Peace,
    ET

  5. Dave Laribee says:

    > Can we agree that an anemic domain model should be pursued first

    Yes, when choosing a domain model or a domain model style architecture for the model layer. It’ll then be a lot like AR.

    > The rabbit hole gets deeper.. :-)

    Heh… it does, sometimes. I think, though, that we have to be mindful of complexity – sometimes is us making things difficult as in lack of understanding/impatience – and sometimes, sure, it’s the problem domain.

    I simply see anemic domain model as more of a fancy way of saying “you say you have a domain model but you don’t” than anything. it’s only really a harmful anti-pattern in domains that are really complex.

    I like, as you say (?), anemic model as a model layer architecture where context binding and core abstraction in certain, more-complex parts (to dig into more DDD-ness) happens. Damn that’s jargony. Treated complexity. I call this a dropstone architecture (see link in post) and it’s more-or-less the path we’re pursuing with our product.

    Anyway, yeah, this went in a whole new deeper direction but we agree methinks :)

  6. Joe Ocampo says:

    Looks like we are approaching this at right angles and saying the same thing. :)

    This is a good thing. Simplicity of design and approaching DDD practices as an engineering tool set of concepts that fits within contextual boundaries makes sense.

    Can we agree that an anemic domain model should be pursued first. From there if there is a bounded context that steps outside the anemic simplicity than additional distillation can occur threw the model to achieve greater insight into a more complex issue? The rabbit hole gets deeper.. :-)

    But what guidelines can we give in order to asses when and when not to distill?

    >I have a couple of presentations coming up on this subject, do you mind if I quote you?

    Feel free to use the quote, if it provides greater understanding of DDD I am all for it!

    >You’re not really sorry are you now :)

    I will keep that to myself. :-) You are right that I saw this coming, DDD especially when both sides have a good understanding of it, can go on and on and on…. Which is why I know longer participate in DDD forums on Yahoo.

  7. Dave Laribee says:

    Wow.

    I think a lot of DDD stuff can be teased apart and applied all over a codebase. Ubiquitous language, for example, is a good idea practically everywhere from every angle. Side-effect free functions, anti-corruption layers, core subdomains, etc. A lot of these concepts can be pulled in in various layers and at various points w/o having to follow the whole style which isn’t a connect the dots approach as you and I both know.

    > we owe it to our product owners to help them model their business domain as best as possible

    This is an interesting point you make. If there is no applicability of domain model I wonder if any software merits developing? Seems there’s always a kernel of complexity that can benefit from more than less of the tricks from the DDD bag. Hmm… worthy of consideration?

    > As it can easily lead towards entropic tendencies

    Sure. But let’s not confuse ourselves that until those areas exhibit complexity they need more than active record. Let’s find ways of refactoring and mutating those assets into a domain model terms when needed. Also let’s not reject simplicity as anemic domain model. Simplicity is to be cherished and it can be found in code that expresses Entities, Repositories, etc. that looks anemic when in fact it’s just right.

    > I view modeling like I do story telling, it should be easy, fun and everyone should understand the meaning.

    I love that. That’s just great! I have a couple of presentations coming up on this subject, do you mind if I quote you?

    > Sorry for the :-)

    You’re not really sorry are you now :)

    Thanks for your awesome feedback! Your comment could have been a post! As could this response, perhaps you saw this coming and wanted to prevent an infinite volley of post tennis…

  8. Joe Ocampo says:

    The discipline of determineing when and where to apply DDD seems to be the problematic issue.

    During a modeling meetings, the “ubiquitous language” emerges from the domain model harmonizing the vocabulary of all stakeholders. Models can be talked towards to reference domain issues and elucidate to greater incite for the team as a whole into problem issues surrounding a story that would have other wise gone unnoticed. Assessing complexity of a domain area from a high level is no small order since the product owners assumptions that lead to complexity are sometimes locked in their heads and cannot always be captured from a simple story or acceptance test.

    Should the whole system be modeled, No. But lets define what we mean by system? Are we talking strictly about the domain layer? Or are we talking about all layers being modeled from the view, to the controller down to the repository. If we are talking about the latter then I would agree this is overkill and a waste of time. If we are talking about the former than, I feel we owe it to our product owners to help them model their business domain as best as possible.

    The value surrounding Entities is apparent it’s when you delve into the political correct modeling world of what is and what isn’t a Value Object that the complexity of models start. Then we debate on when and when not to apply Factories, Services, Aggregates and Repositories. Once we are here modeling can easily lead to chaos if not properly facilitated.

    AR frameworks are wonderful as they lead to ease the pain of defining repositories services and speed up development effort. But to say don’t model because you are doing basic CRUD operations is something I would caution on. As it can easily lead towards entropic tendencies.♠

    I view modeling like I do story telling, it should be easy, fun and everyone should understand the meaning.

    Sorry for the :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>