Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
I think we'd need to see some specific examples of your particular case to help out. –  Martijn Verburg May 1 '11 at 9:14
1  
Sorry, I meant code snippets :) –  Martijn Verburg May 1 '11 at 9:25

4 Answers 4

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
2  
+1 for "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." Well said. –  Andrew Theken May 11 '11 at 20:22

For starters: DI and IoC are not synonyms. I am sorry but I most 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 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.

share|improve this answer
    
I'll add to this that perhaps you could take a peek at the DDD approach espoused by Eric Evans et al. –  Martijn Verburg May 1 '11 at 9:42
    
I did read Eric Evans' book. It is good for general methodology and ubiquitous language, but somewhat lacking in real-world examples. –  Mag20 May 1 '11 at 9:47
    
Thanks for pointing out the difference between DI and IoC. I think the issue had more to do with IoC then DI. Changed the question to reflect that. –  Mag20 May 1 '11 at 9:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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