I took a JavaEE course today and I was presented to the "default" JavaEE architecture, which consists mainly of Entities, Services and DTOs. The guy presenting the course explained that it was indeed a case of anemic models, but however this was the "in facto standard JavaEE architecture".

I am new to JavaEE, but I've head some experience with other languages. The first time I read about beans as components, I thought they would be great to create a DDD-like architecture.

It sounds strange to me that a "standard architecture" has a anemic domain (I, until now, thought it was a "bad smell").

Is there any technical reason or big advantage of using this architecture? Why an architecture that defines its models to be anemic is the current standard?

I asked him and he talked about transaction context, but I have to admit I didn't understood exactly what he meant.

  • 1
    Have you read this? en.wikipedia.org/wiki/Anemic_domain_model – Robert Harvey Apr 22 '15 at 18:45
  • yes, it states that it is OK for many "simple applications". I would say that a JavaEE application would be usually not simple. – JSBach Apr 22 '15 at 18:50
  • Is "It's old" enough of an answer to you? Do you understand almost no-one gave a crap about patterns and anti-patterns 10 years ago? (even if some where already defined, really... no-one gave attention to them) – ZJR Apr 22 '15 at 18:51
  • Hm, I understand. The problem now is that everybody continues doing the same thing because now "It is the standard" and that is sad :( – JSBach Apr 22 '15 at 18:54
  • @ZJR Disagree - the classic "Gang of Four" patterns book was published in 1994, well before J2EE (1999). "They" should have known better. In fact, they did take many of the patterns like Factories. IMO, J2EE (especially the initial versions) was a horrid botched non-OO mess that opened the door for better systems like Spring et. al. It also triggered wonderful diatribes like the Kingdom of the Nouns. – user949300 Apr 22 '15 at 18:58

I see this in the .NET world as well and I have so far identified a handful of reasons as to why this happens (I also do not prefer anemic data models).

  1. Old code. People didn't know better and it's too expensive to rewrite.
  2. Misinterpretation of the DRY principle. People want to use their objects as contracts and send them over the wire as XML/JSON and then prefer to make them into simple DTO's - and instead of using these as contracts and then translating them to real domain objects at the boundaries people go to the anemic domain model antipattern instead in order to not have two objects representing the "same" object.
  3. The application is actually not complex enough to warrant a domain model.

Now, in 1 and 3 an anemic domain model might actually be the right choice. Having a rich domain model can be a lot of work which may not actually provide enough value given your application. Many applications, even in the JavaEE world, are just glorified CRUD-layers on top of a database. If there aren't enough domain logic, anemic domain models can actually be the correct choice.

In 2 however I'd say that it's just bad practices. If you have an application with a domain that is rich enough to warrant a domain model then you should have one. According to SRP each object should have a single responsibility, DTO's by design already have one responsibility - represent the data transfer format between your system and an external system. You should not use them for anything else. There should be a mapping layer (which in these days are much faster to write than they've ever been before since there are plenty of frameworks/libraries that can remove a lot of the busywork in writing these) that maps from the DTO to your domain objects and vice versa - and then your application should only use these domain objects to perform its intended purpose. This also gives you the chance to refactor and change your implementation independently of changing your external contract - and this is a huge gain once you're in production.

But yes. It can be a lot of extra work, and the really hard part about this is looking at your domain and asking the question "Does this domain motivate going full on DDD?". And you really shouldn't underestimate that question, it's actually a really hard one.

| improve this answer | |
  • Great answer. Yes, DDD seems (I haven't used in a real project, but I would love to try) to have some extra work at some points, but my experience with services is that at some point they start to grow in size and complexity and are thus harder to reuse. I've found a service-architecture project that had many similar methods because they had small differences and merging them would result in a very complex service. – JSBach Apr 24 '15 at 7:47
  • Obviously this can be due to bad implementation of this pattern. However, I have the feeling that DDD makes separating methods in smaller parts that make sense easier and using polymorphy easier. – JSBach Apr 24 '15 at 7:47
  • 1
    Yes, that is my experience as well. I have used both patterns in real projects and I greatly prefer DDD even though it can be some extra work just for those reasons (and some others). But for smaller less complex projects the service-architecture style can be "good enough". But it's also important to say that it's not all black and white, it's perfectly possible to use parts of DDD in a service-architecture and get a decent middle ground. I'm for example a big supporter of identifying and using value objects as much as possible no matter architecture. – wasatz Apr 24 '15 at 9:25
  • 1
    Of course, if you go the "middle ground" route you shouldn't actually tell people that you're "doing DDD" since you're really not and people can get very annoyed when you misuse the term. ;) Just say that "this class is using the value object pattern from DDD" or something similiar. Communication is important, and as an industry we have a tendency to mislabel things quite often causing a lot of unnecessary friction, arguments and other bad stuff among ourselves :/ – wasatz Apr 24 '15 at 9:28
  • 1
    "people go to the anemic domain model antipattern instead in order to not have two objects representing the "same" object.". bingo. The problem is that people are comparing objects by the data they contain instead of the behavior they encapsulate, which imho goes against OO design. – Andy Apr 24 '15 at 21:54

Typically you domain objects would cross layers and also process boundaries. So your Domain objects which are typically POJOs are essentially the contract between layers and processes. Contracts should define the expected structure of inputs, outputs (and exceptions) not the business logic. This is true weather you are writing enterprise code or otherwise.

Keeping the domains light weight and bare-bones ensures that the conversion (serializations in various forms) takes place easily. Here is an example - your domain gets spitted out by Jersy Clients as a JSON object - now if you object has a lot of BL and dependencies - the conversion or serialization to JSON will be complicated and unwanted knowledge will be passed on to the client which only cares for the data.

That is not to say your objects have to be dumb! If you can reduce redundancy in the object by providing one field with some additional getter methods for convenience by all means go ahead and do it - example if you have unit cost and quantity fields in your POJO but for display you typically need the total price go ahead and add it as a getter without introducing a new fields (redundant) - make sure you provide no setter method for it only getter. this kind of border lines with BL but it isn't if the role of your services is a lot more involved than computing price.

| improve this answer | |
  • 3
    "Contracts should define the expected structure of inputs, outputs (and exceptions) not the business logic.". interfaces are contracts (and in .net Code Contracts lets you define real DbC contracts which are enforced), not objects. The anemic models you describe effectively revert OO back to procedural programming. Pojos which are designed around being serializable aren't domain objects at all, models should not be anemic, the should be the source of truth for whatever they represent. – Andy Apr 23 '15 at 0:33
  • 1
    @RobertHarvey You would have anemic models in the "transfer layer", they would be DTOs or somethink else, so you can avoid the json/xml parsing issue, but I wouldn't call them "business model". Ideally I would map them to non-anemic-models in the boundaries and process this non-adnemic-model inside my system. What are your opinions about it? – JSBach Apr 24 '15 at 7:57
  • 1
    @YazadKhambata the state is encapsulated in anemic models but not the behavior. when you're talking about two different platforms you're inherently talking about two different applications which are different bounded contexts. You'd connection them probably via web service but the service contracts are just service contracts, they do not have to represent the shape of the domain models the service uses to do its job. – Andy Apr 24 '15 at 22:09
  • 1
    @RobertHarvey rather you can't move logic between two platforms. Logic is code, not data... unless you're going to write something that converts between one language to the other on the fly. Finally web service contracts are NOT the same thing as domain models. If you're tying those together you're asking for pain. – Andy Apr 24 '15 at 22:13
  • 1
    @Oscar agree, you would not directly expose your domain model with a web service. You'd do just as you said, with the service built on top of the domain layer just like any other client interface (GUI, command line, etc.) – Andy Apr 24 '15 at 22:18

This does not mean J2EE applications are based on skimpy models it just that you can implement any more complex model using only entities, attributes and relationships.

In the same way you can implement any control structure (for each, while, do until) using only if and goto.

There is no need for the more sophisticated concepts to be part of the implementation.

The real problem is that while DDD may look pretty on a diagram no-one has come up with an elegant way to translate these concepts to code.

I used to be a big fan of generating code from models, but, now I have many doubts. The model is now source code, which needs to be under the control of the implementer/programmer if you want the system to work and perform well, however, the designers and modelers are used to hacking the model and traditionally have no concerns about any implementation issues. In effect the model which used to be a communication tool and the interface between designers and developers has become a battleground between the designers who want an elegant and accurate description of the requirements and the developers who need a precise and often quite ugly model to generate efficient code.

| improve this answer | |
  • Hi James! I don't know if I missunderstood your answer, but when I talk about DDD I do not mean generating code from diagrams and so on, I mean Domain Driven Design, which hash a great book about it amazon.de/Domain-Driven-Design-Tackling-Complexity-Software/dp/… I haven't tried that in a real project, but it seems elegant to me at a first glance :) – JSBach Apr 24 '15 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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