How to make the best of an Anemic Domain Model given no other choice

Question

So I started my 2nd developer job after spending 10 years at my first company and not really feeling I earned the title of a senior developer. It was java development but we were working with an anemic domain model and the application in my opinion was a huge difficult-to-test mess. Unfortunately the code base that I'm working with now is exactly the same and I recently had another interview where the interviewer described their Hibernate model as being light weight and just containing setters getters as well. So it appears this is quite common across the industry.

There's plenty of articles describing the anemic domain model as an anti-pattern and also some articles where it is described as perfectly fine for simple systems. But I haven't seen any examples of making the best out of working with a large enterprise system with an ADM.

Has anyone had experience with this? Are there any best practices for creating a loosely coupled system that contains unit tests that are readable and actually valuable? I really want to take pride in my work but am losing hope.

Edit: To the developers that advocate business logic being contained in services:

• how do you limit the dependencies on other services within each service? i.e. OrderCancelService needs CustomerAccountService and PaymentService and RefundCalculatorService and RewardsAdjustmentService, etc This tends to lead to several mock objects in tests making tests way too tied into implementation

• how do you limit the number of parameters in each service's method? Since everything needs to be passed around and objects don't operate on their own data, this seems to lead to very large and confusing method signatures

• Do you apply tell, don't ask principle to service objects? I see a lot of services that return values which are then used by the calling service to make decisions in execution flow.

Answer 1

You may consider your persistence model, which you now think about as the anemic domain model, as what it is - the persistence model for your domain model state.

If you do that, you probably can create a real domain model, which will have its state stored inside the persistence model objects (State pattern). Then, you can have your logic inside this new domain model. Reading your comment above, I would say you can convert your "manager/service" classes to state machines, you can call them aggregates if they match with transaction boundaries, and have their state in POJOs persisted by Hibernate as it is done now.