0

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.

WorkinHard
  • 1
  • 1
  • Just to be sure, you mean an anemic model for a *complex* problem domain, not for a simple, CRUDish one, right? – guillaume31 May 17 '17 at 08:12
  • @guillaume31 Yes that is what I'm struggling with. Having many different workflows triggered by many different user interactions each of which make decisions based on several properties in several entities and each of which update several properties as well. This seems to result in an explosion of large service/utility/manager classes. So given that I cannot move logic into the entities, how do we do our best to apply SOLID principles and apply TDD as emphasized by agile development. – WorkinHard May 17 '17 at 14:43
  • Welcome to the industry. Actually is really HARD to join a team that applies DDD and TDD correctly or to join a company where you can change stuff. All I can say is that you should try to figure all this out on your own while being interviewed. Even wearing an architect hat it might be hard depending on the company culture, so just keep looking for it and do not give up! Attend ddd courses, try to get involved in the community in person and make contacts :) – Sebastian Oliveri May 23 '17 at 19:50
  • If this is the industry, what makes a senior developer senior? If it's not his ability to implement a clean flexible system. Is it purely knowledge of different technologies? – WorkinHard May 24 '17 at 17:59

1 Answers1

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.

Alexey Zimarev
  • 17,944
  • 2
  • 55
  • 83
  • I think it will be difficult to convince a team to hide our JPA entities inside java classes with the same names. I'm wondering if there are best practices for these stateless services that tend to surround each entity i.e. OrderService with methods like cancel, addOrderLines. To the developers who advocate logic being in service layer - Are there any best practices such as not having getter methods on these services and ways to limit long parameter lists such that unit testing and mocking can be made cleaner? – WorkinHard May 23 '17 at 15:43