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!

Welcome to the Anemic Age

Just a quick run by posting. It seems that all the cool kids are now building apps using anemic domain models


The recent document  Two tier application scenario (REST) from MS P&P is a good example. While I am picking on P&P here this is by no means an uncommon piece of advice please bear with me that this is GUIDANCE being put out. Update as if that was not bad enough the same guidance also makes up the Three Tier Web Application Guide it looks as if this will just be Microsoft’s new guidance.


I love that “behaviors” are described in a single line as being “transaction script services”.

I have been seeing this trend for a while now.  I had thought that we had all learned our lessons years ago about anemic domain models…. oh wait that was the java community it will be different this time.


I think part of the problem is that coming up with the RESTful architecture is so much more neat for an astronaut architect because its happily generic and can be described well in an architectural document or even better by a framework. I mean to deal with those “system behavior transaction scripts” you might  actually have to talk about … the business, and you can’t write a simple document/framework to describe how to handle it.


As this guidance (like most) will be followed blindly by 90+% of people who read it, I would like to be the first to welcome you to the Anemic Age. Procedura code is dead, long live procedural code!


Update: Great quote

“What strikes me most about the P&P
article is that the seems like it would perform best in a forms over
data app.  But if you really have a forms over data app, then the
architecture is way too complex.”. Bingo, I actually had a similar conversation with someone else today.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

33 Responses to Welcome to the Anemic Age

  1. @ Andrew

    Point taken. Having worked in Developer Support in the 1990s, I’ve been on the receiving end of both bad designs and bad guidance. p&p does understand its responsibility. I have to point out that is not in a printed book, downloadable PDF or code marked “stable”. It was out less than a week for feedback when this all occurred. I think if we are guilty of something, it’s not knowing which people in the ALT.NET community to consult during the Alpha of the guidance. We have now remedied that situation. :) We’ve also clearly marked the article as BETA on the site so that people will not take it blindly and use it as is (we would hope).

    We are now having extensive (and I do mean extensive) conversations with Greg Young, Colin Jack, Sebastien Lambla and David Ing. We aren’t saying that the article is “wrong” because this has to be measured against a scenario, but it’s obviously very misunderstood. As such, we’ll be fixing this article so it has consistent terminolgy and proper explanation. We will also be facilitating another article that would show how these folks feel it should be done. We’ve also talked about a full DDD article with open source that will be on our contribution site. http://www.codeplex.com/AppArchContrib.

    We don’t mind people having a problem and expressing that strongly. Just use that energy to help fix the issue. I want to thank the guys I mentioned above for doing just that.


  2. jsmith says:

    @Andrew: Good grief, I just said they were whining about the feedback, you called them professionally irresponsible.

  3. Microsoft is generally pretty good in “reading the market” and a development model based on anemic domain model and transaction script is exactly what most of the market was looking for. Does it mean it’s a good thing? Not necessarily.

    But Lee is right pointing out that methods must match the team, there is no point in applying a full-fledged DDD approach if the team isn’t string enough on OO fundamentals. The Transaction Script model is easier to understand for most developers, it’s definitely not the best one, but that’s where the masses are going. (and by the way this is exactly what happened on the java side, right after the EJB bloat collapsed…)

  4. Andrew says:


    Fantastic attitude there, got to love those internet tough guys.


    You weren’t whining, so don’t worry about the few people that use the internet is there own little space where they can act out to feel better about there own shortcomings.

    There is no need to reshash the issues with the p&p codeplex project(s) because they have been laid out by people much smarter than I. But I do hope that your team does learn from them and puts out new release with all of the concerns addressed.

    Whether it’s fair or not, if you put something out there it’s perceived to be “right” by the masses. The reality is, there are too many programmers out there, especially in these tough economic times, who are asked to perform well beyond their abilities (and pay scale). When they see a MS released Best Practice (or p&p, or whatever, it’s all symantics at that point), they will blindly adopt it, even if it’s over complicated or incorrect.

    It’s all good to want to get stuff out there because “we’re doing agile”, but you’ve got a responsibility that 99.9% of the worlds programmers don’t have, and that should be taken into consideration before releasing anything.

  5. Thank you all for bringing this up.

    No whining intended.

  6. jsmith says:

    then consider yourself fed-back
    stop whining
    and say “thank you”

  7. Hi Folks,
    As a member of the team responsible for these p&p articles, I just wanted to make a few points clear here.

    This is not official guidance at this point, but it is inteneded to be eventually. It’s on codeplex, which we mean to be a place for things to be in beta. MSDN is official. We work using agile, which means we put things out before they are done so we can get feedback and improve them. Since there has been so much confusion on this point, we’ve marked all these app patterns as BETA.

    The app patterns are not meant to be the only way to do something. They illustrate one way.

    That said, obviously the community (all of you) have some issues with the content. We are glad to hear any comments. We want to make the content better.

    If you’d like to make any of these items better, you are welcome to leave feedback on wiki pages showing the actual content. Colin and others have already started to do this and we certainly appreciate that. One of the original writters of these patterns is making comments on those pages right now.

    All of the app patterns are referenced from this page.


    Rob Boucher Jr

  8. Paul Kohler says:

    I can see the points above – i.e. “but how does it work” with respect to not putting the logic in different layers etc. An post/example would be great but I am sure there are good examples out there that you can point us to. I still tend to be “old school” by default when designing a model but appreciate where DDD is focused. Is there a good .Net Open Source app that fulfils the DDD approach you could point us to as a reference point?
    I think I have done most of my learning over the last few years from blogs and OSS!!

  9. Kasi Prasad says:

    While I think that Anemic domain models are certainly not what we strive for when developing OOP apps (objects should contain state + behavior, even if its behavior is to orchestrate the behavior of smaller sub-parts), it seems Microsoft won’t quit offering guidance that is biased toward a data-centric view of development. It seems that Microsoft isn’t willing to accept (at least in it’s guidance both public like through the MSDN and private through its Official Curriculum (MOC) training offerings) the fact that on many occasions we are developing more than a simple data over forms, auto-magically generated, short-lived application.

    As an MCT the hardest part about delivering MS training is trying to help students un-learn most of the guidance MS has provided that has directed them to focus on the data rather than the behavior the systems they develop.

  10. Colin Jack says:

    As Bryan said I think you’ve gotten things backwards, plus SRP is really about a single reason for change, what you are really talking about are data structures: http://blog.objectmentor.com/articles/2007/11/02/active-record-vs-objects

  11. fregas says:

    I’m pretty ignorant of REST architecture, but Anemic domain model is how microsoft does everything. I don’t know how they managed to build the dotnet framework. I remember some of their other example frameworks (Enterprise Application Blocks?) had dumb objects with no behavior and data only.

    They do this over and over again: Entity Framework while allowing behavior thru partial classes and such is almost entirely data-centric. WCF has limited support out of the box for doing old remoting style of marshaling of .NET objects with behavior–they want you to build everything SOA style. So no surprises here. I honestly believe that to MS, OOP and DDD are dead.

  12. Bryan Watts says:


    Objects are about encapsulating data and the behavior which uses it. Without behavior, you are missing half the impetus for an object, and that smells.

    Data + behavior is the responsibility of *every* object; that doesn’t count against the SRP tally.

  13. Lee Campbell says:

    @BjartN @Erik @jorge
    Moving away form the org post on REST, but I think Anaemic Domain Models and Transaction scripts represent one end of a a continuum and Mega-Objects bloated with responsibilities lie at the other end. While I have the utmost respect for Fowler, I found that I had to digest “Implementation Patterns”, “Refactoring” and then tackle Evan’s “Domain Driven Design” book to appreciate where Fowler was coming from w.r.t Anaemic Domain Model. My take is that there is a balance of Coupling and Cohesion that needs to be made. Also to be fair the method needs to match the team. 80% of devs don’t wont be able to handle anything more complex that TranactionScript. :-( I think this is understandable (not forgiveable) as most devs are still trying to learn generics, lambdas, WCF, WPF, Azure, jQuery, AOP……

  14. BjartN says:

    If you fill up your domain objects with all kinds of business logic you’re ignoring the single responsibility principle are you not ?

    Your domain objects are both responsible for business rules and also for holding the state of the object. With alot of business rules you will get a big ass object.

    So what would you go for ? SRP or a big ass object ? Or can you have both ?

    What about keeping business logic close to the domain object, but not in it ?

    Just Wondering..

  15. Greg says:

    @jorge the easy answer revolves around what you define their “Responsibility” as …

    if I have code such as …

    Customer c = GetCustomer();
    c.Status = CustomerStatuses.Deleted;
    c.DateDeleted = DateTime.Now;

    outside of a domain object … I would argue that *THIS* is a violation of SRP.

    Does that make sense?


  16. Greg says:

    @Taz: troll much? I think my response to AC was contextually appropriate.

    @AC: There are still behaviors in a RESTful architecture.

    Let’s assume for a minute there weren’t…

    1) Why would we need transaction script behaviors in the first place?

    2) Why would we not just use a framework to push our EDM over a restful interface? Why would we have this convoluted nightmare if we had no behavior to support? Domain models are only really useful for expressing behaviors there are better (cheaper) ways to model data.

    There are however “behaviors” in a RESTful system. A quick thought about this shows that even if REST were CRUD that 2 CRUD models can equal behavior. Imagine for a moment that I have a public CRUD model for “orders” that has an “Approved” flag. When you set the “Approved” flag I use a behavior in my domain model of approving the order (there is no “approved flag” in my domain). Another way that this could be handled would be to have a url that you can post to to “Approve” the order.


    Beyond that go take a look at “End session” in the twitter API for an example.



  17. jorge says:


    Do you think you might be able to put together a post on anemic domain models? I’ve read the Fowler article at least a dozen times, but have to admit to not seeing a solution to the problem. How do my entities have behavior without violating the SRP? If my entities contain behavior, how to I use DI to get the appropriate business services into them? Is there source code to a well written application that you can recommend looking at? Appreciate any further elaboration that you might have time for on this subject.

  18. taz says:

    AC, I think a lot of the guys on codebetter.com are a little arrogant. Sorry your questions were not answered in a respectful and mature way.

  19. Paul Kohler says:

    Oh the pain of following the “leader”!

  20. Greg says:

    @Erik I think I like to Martin Fowler’s discussion on the topic above. That is a good place to start.

    @Ryan yeah pretty much :)

  21. Erik says:

    The all the time since I’ve heard the term ‘anemic’ describing domain models, all I’ve ever heard is that they’re bad – but I’ve *never* heard why. Can you help me with that, Greg?

  22. Ryan Roberts says:

    That transaction script handler is just horrible, even forgetting the services over data architecture. Object[] data as parameters, subscript access, null bomb casts and sprinkled with infrastructure calls.

  23. AC says:

    I apologize for coming across as an ignorant jerk. I also acknowledge that Microsoft screwed up recommending transaction scripts for implementing internal behavior. But the issue still remains that REST has exactly 4 verbs: GET, POST, PUT, and DELETE. In a RESTful app you can model it as a state machine with hyperlinks between states, but the external interface is still a pure CRUD interface which I would argue is the very definition of anemic. REST proponents say the uniform CRUD interface is a feature, not a flaw. It appears you’re saying that REST is anemic in a bad way, but perhaps I’m misreading you.

  24. Ryan Roberts says:

    “represents the relationship between entities in the domain but does not contain behavior or rules related to the entities”


  25. Ollie Riches says:

    Is the ‘Anemic Age’ related to the ‘Anaemic Age’ at all Greg? and yes I’m being in ass if the other replies are to go by.

    But I do agree with your prophesy…

  26. Colin Jack says:

    How come my comments lose all there formatting, makes it look like I’m talking utter rubbish (rather than just 90% rubbish).

  27. Greg says:

    @AC There are many good books available on REST. Perhaps you should try reading one before making comments in such a tone on someone’s blog because it just makes you look like an ass.

  28. Colin Jack says:

    Are you really and truly serious? Really? If so go read what Microsoft tells you about REST and good luck, since there article covers domain modeling and REST and a bit of messaging you’ll have every success with it.

    If however you want to learn REST/WOA/ROA properly perhaps go do some reading about it in general. If you still think REST is CRUD over HTTP after doing that then there is really something wrong with the world

    Also Microsofts article was bad not just on REST but on OOP/DDD/design/terminology.

  29. AC says:

    Isn’t REST all about exposing CRUD operations via HTTP? If so, then how do you get behaviors beyond resource-oriented CRUD? Transaction scripts seem to be the most straight-forward option. Please enlighten us to the alternatives while still being a RESTful system.

    If you are taking issue with REST in general, then please state it as such rather than “MIcrosoft sucks because they tell you how to make things work if you’re starting with REST as your core architecture.”

  30. Colin Jack says:

    I’m still writing my list of complaints with the article but here’s my reaction: http://www.lostechies.com/blogs/colinjack/archive/2009/01/22/p-amp-p-web-service-with-rest-application-pattern.aspx

    “I think part of the problem is that coming up with the RESTful architecture is so much more neat for an astronaut architect because its happily generic and can be described well in an architectural document or even better by a framework.”

    As I said over messenger I think if these guys did a series on “Application architectures with DDDD (MEST)”, they’d make same mess of it. The article has as much to do with REST as it does with DDD or OOP, exactly zero.

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>