Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
When I used IoC Container in my last project, I ended up with anemic entities and most of my business logic in Stateless Services.
I have seen projects written by other developers that utilize "Inversion of Control" and they are always "Anemic".
Since "Anemic Domain Model" is anti-pattern, is it possible to use IoC and Rich Domain? Are their any good examples, open source projects that do that?
For starters: DI and IoC are not synonyms. I am sorry but I must point that out (it seems to me that you think they are).
As for your inquiry... Well, Dependency Injection is just a tool. How you are going to use this tool is completely separate thing. There are also other tools (design patterns) that could add up to the problem. For example, I feel that wide adoption of MVC pattern is one of the key ingredient to forming Anemic Domain Model anti-pattern: Controllers (in simpler applications, in more complicated ones that would be additional Service Layer) take on responsibility for validating business rules, enforcing them as well as transforming DB entities into something useful, whereas Business Layer turns into simple Data Access Layer that is plain ORM with one-to-one mapping to database entities.
Certainly it is how you design your application — you can create a correct Domain Model if you want, and all these IoC, DI, MVC do not stop you. What could stop you is your team. You somehow need to convince them to use the right path and it might be hard as many Software Developers do not have strong architectural background.
Most (if not all) applications are a mix of infrastructure and domain concerns. When you reach a certain level of complexity you'll make it easier to manage if the domain is separated from the infrastructure so that it is easier to reason about and can evolve independently.
Of course the domain model still needs to communicate with the rest of the system and usually this will be with stateless services (which are part of the domain) that have infrastructure concerns (such as database access) injected into them. Using an IoC container doesn't remove this dependency, it moves its configuration into a separate area - again making it easier to reason with and maintain.
The entities are storing state and should be responsible for the business rules. If your services are enforcing all the invariants and other business rules then it's likely that logic is in the wrong place.
Now if you've got the logic in the right places and yet have still ended up with services that are no more than wrappers around infrastructure things and entities that are just property bags then it's very likely that the domain isn't complex enough to justify the overhead of its own model. Just about anything you'll read about DDD will contain a disclaimer that its really only intended for complex domains, but this seems to be all too often forgotten.
Go to the source. Start with Fowler's piece on Anemic Domain Models. He references Eric Evan's Domain Driven Design as an example of good practice. The source code for that is here. Download it.
Observe that it uses Inversion of Control (search for @Autowired), and has service classes (BookingService), and "business process" classes (e.g. ItineraryUpdater).
Fowler's original article starts the trail to the example you are looking for.
VoyageRepositoryHibernate class, which was put in the infrastructure layer but actually depends on the domain layer.
save(foo) with code that is subject to change when the domain model changes (for example, if a new attribute is added to MyDomainObject), then it must (by definition) belong to the domain layer; otherwise, you just can't talk about having "layers" anymore.
is it possible to use IoC and Rich Domain? Are their any good examples, open source projects that do that?
I assume you mean DI instead of IoC, and the project you worked on uses a DI container like Spring. IoC has two main flavors: DI and Locator pattern. I don't see why the Locator pattern should be a problem, so let's focus on DI.
I don't think it's possible, or at least would be very impracticle. The main aspect of DI containers is that they control the creation of objects when they inject them into others ("managed objects"). The set of managed objects that is alive when the projects runs is independent from which domain items exist in your project but depends on how objects are wired and which scopes (singleton, prototype) are assigned to them.
This is why you don't want to let the DI container manage your domain objects. But if you create objects manually (with new), you can't get other objects injected to your domain objects. (Leaving potential work-arounds with manual wiring aside.) Since you need these injections to replace implementations with others, you can't replace the functionality of rich domain objects using DI. Hence, you will not want to place functionality into domain objects, or you'd lose the features of the DI.
I don't see how a hypothetical DI container could work that doesn't manage your objects, and none of the existing implementations allows that. So it's fair to claim that DI relies on managing objects. It will therefore always tempt you to split potential Rich Domain objects into one anemic class and one or several transaction script classes.
