Facilitating the spread of knowledge and innovation in professional software development

Contribute

### Topics

InfoQ Homepage News Article: Domain Driven Design and Development In Practice

# Article: Domain Driven Design and Development In Practice

Domain-Driven Design is a subject where there currently are very few examples of how to actually do it in practice. In this article, Srini Penchikala gives you guidelines, practices, frameworks and tools that technical leads and architects can use in the effort of implementing a system in a Domain-Driven way.

From the article:

Domain Driven Design and Development is also influenced by several architectural, design, and implementation aspects such as:

• Persistence
• Caching
• Transaction Management
• Security
• Code Generation
• Test Driven Development
• Refactoring

This article talks about how these different factors affect the implementation project throughout its lifecycle and what the architects should look for in realizing a successful DDD implementation. I will start off with a list of characteristics a typical domain model should have, and when to use a domain model in an enterprise (versus not using a domain model at all or using an anemic domain model).

After that initial effort, Srini guides you though Project Management, Architecture, Design, Development, Unit Testing/Continous Integration and Deployment of a domain driven application. A sample applictaion is provided with the article.

If you want to understand how annotations, dependency injection, code generation, transaction management, data transfer objects and many other things fits into a DDD-context - read the full article on Domain Driven Design and Development In Practice.

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

• ##### It's wonderful!

by Laurence Geng,

• ##### Re: It's wonderful!

by Laurence Geng,

• ##### Re: It's wonderful!

by Srini Penchikala,

• ##### Re: It's wonderful!

by James Bao,

• ##### Re: It's wonderful!

by Lindsay Holman,

• ##### Re: It's wonderful!

by Mattias Fagerström,

• ##### Re: It's wonderful!

by Srini Penchikala,

• ##### Re: It's wonderful!

by Srini Penchikala,

• ##### Re: It's wonderful!

by Lindsay Holman,

• ##### Re: It's wonderful!

by iury ribeiro,

• ##### Re: It's wonderful!

by Lindsay Holman,

• ##### Re: It's wonderful!

by Srini Penchikala,

• ##### Re: It's wonderful!

by Felipe Guarneri,

• ##### One observation.

by Leonard Petrica,

• ##### No asserts in the tests

by Peter Bona,

• ##### Re: No asserts in the tests

by Srini Penchikala,

• ##### Mixed feelings

by Yuriy Zubarev,

• ##### Re: Mixed feelings

by Lindsay Holman,

• ##### Re: Mixed feelings

by Srini Penchikala,

• ##### Re: Mixed feelings

by Yuriy Zubarev,

• ##### Re: Mixed feelings

by Lindsay Holman,

• ##### Re: Mixed feelings

by H S,

• ##### What am I missing?

by Rob Rudin,

• ##### Re: What am I missing?

by Phatthana Sitthideth,

• ##### Re: What am I missing?

by Srini Penchikala,

• ##### Not even close to DDD

by Kaushik Selvaraj,

by 李 引,

• ##### It *completely* misses the point...

by Ronald Miura,

• ##### Re: It *completely* misses the point...

by Dustin Woods,

• ##### Re: It *completely* misses the point... Not!

by Geert Pante,

• ##### Re: I *completely* agree

by Dimitris Menounos,

• ##### Re: I *completely* agree

by Srini Penchikala,

• ##### Re: It *completely* misses the point...

by Ronald Miura,

• ##### It's Great

by Ravi Koda,

• ##### Domain-Obects Java Classes not so intuitive

by Ilya Boyandin,

• ##### DDD on 3 tiers (Differents JVM)

by iury ribeiro,

• ##### Re: DDD on 3 tiers (Differents JVM)

by Srini Penchikala,

• ##### Sculptor

by Patrik Nordwall,

• ##### Re: Sculptor

by Srini Penchikala,

• ##### Naming throwing

by Eduardo Miranda,

• ##### Re: Naming throwing

by Srini Penchikala,

• ##### Re: What about the Grails approach?

by Soner Dastan,

• ##### Re: What about the Grails approach?

by Srini Penchikala,

by Nima n,

• ##### Re: DDD and agile

by Srini Penchikala,

• ##### Domain objects should not call CURD operations

by Sandeep akhare,

• ##### don't inject repository into model

by Peng Sunny,

• ##### Domain Layer uses the Infrastructure Layer. The layer below it.

by Roy Oliver,

• ##### A comment on the sample application

by Enrique Molinari,

• ##### Very bad example application, practically anti-DDD example

by Georgi Danov,

• ##### Re: Very bad example application, practically anti-DDD example

by Roman Tmk,

• ##### DDD Modeling tool set

by becky cortino,

• ##### JBoss Business Rules (Drools)

by Dean Peterson,

• ##### It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

It's really great!I have never seen so wonderful DDD implementation,especially it bases on many mainstream frameworks such as hibernate,spring and so on. For the DDD,Eric Evans gives us theoretic guidance,and I am sure,this simple application gives us practical demonstration!Thank you Srini,I sure hope talking about some details of your article and demo project after I seriously reviewed the project.

• ##### One observation.

Your message is awaiting moderation. Thank you for participating in the discussion.

In your class Loan you have CRUD functions like add(Loan loanData) which are applying to other objects. I think is ok to have functions like add() which are operating for the current instance of its class.
E.g.
}

• ##### No asserts in the tests

by Peter Bona,

Your message is awaiting moderation. Thank you for participating in the discussion.

The article is great, but your sample application doesn't have asserts in the tests. How can you test then if your application and domain model behaves correctly?

• ##### Mixed feelings

Your message is awaiting moderation. Thank you for participating in the discussion.

First of all I have to admit it's a great article and I enjoyed reading it. I also looked at the source code and got mixed feelings about FundingServiceImpl class.

loan.add(newLoan);

over
newLoan.add();
for example?

You have "loan" object auto-wired in this class for a sole purpose of persisting "newLoan" as it seems. A domain object is used as a service to persist another domain object of the same type. May be I'm missing something but it doesn't feel quite right.

Thank you.

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

After reviewed your source code,and viewed other peoples' comments,I think it is not very well that the domain object contains the CURD operation.I think it is the repository's responsibility. In a aggregation,we should get objects' refference by navigation from the aggregation root,if the we want to get the aggregation root,I think maybe we can provide a service.

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Laurence, Thanks for the good comments. We, as enterprise developers (Java, .NET or some other technology), focus too much on technical infrastructure details when designing and developing applications. Techniques likes DI, Annotations and Code generation and frameworks like Hibernate and Spring help move away from this paradigm and start focusing more on business domain concerns. This article is an attempt to highlight this paradigm shift and some best practices to implement it.

• ##### What am I missing?

by Rob Rudin,

Your message is awaiting moderation. Thank you for participating in the discussion.

So I read all these grand declarations about DDD in the article, and then I look at the source code, and the domain objects look awfully similar to so-called "anemic" domain objects which are purportedly the scourge of software systems today (I was stunned to not find the requisite link to Fowler's article on the subject). All I saw in these "rich" domain objects were getters/setters for private attributes, some JPA annotations, and then some CRUD methods. What's the big deal here?

And am I the only one who finds a method such as ProductRate.findProductRates() to be a bit awkward in a grammatical sense? Does it really make sense to ask an instance of an object to return a list of instances of its class type? Does anyone actually talk like that in their business domain?

I also found the rhetoric at the top of the article to be conspicuously absent of any proof. "Not investing in a domain model" will "not give the company a competitive advantage over other companies because implementing business requirement changes in this architecture takes too long"? Really? Where's your evidence to back this up?

I've used Spring/Hibernate/AOP/DI/TDD/CI/insert-your-favorite-buzzword/etc on a daily basis for almost the past 5 years. I've followed the DDD movement with some curiousity, but if this code sample is indicative of what it amounts to, I honestly don't understand what the fuss is about.

• ##### Not even close to DDD

Your message is awaiting moderation. Thank you for participating in the discussion.

There are lots of flaws on many levels.

• >> Ramnivas Laddad where he made the assertion that DDD cannot be implemented without help of AOP and DI.

You got it wrong. He said DDD cannot be "adequately implemented" without AOP. I have posted on how you could use DDD without AOP here .

• In your example code, none of your entities exhibit any encapsulation. Why do nearly every field have a getter and setter exposed ? There is absolutely no domain business methods in them. By just exposing CRUD methods in addition to getter/setters how can you even call these domain objects? As a previous commenter had posted, are'nt these still anemic?

Main concept behind Domain Driven Design is adding power to your domain classes which you have not brought out at all. The examples are woefully shallow and cannot be called as DDD examples at all. It is more an example of using spring's DI to inject repositories into DDD. This article does not do justice to elegance and simplicity of DDD.

PS: Next time do some proper research before suggesting matching up various technologies like OSGi with DDD/AOP/Spring etc. If you had any experience implementing either DDD or OSGi you would know that using AOP in OSGi is severly limited. For e.g. aspects have to exist in every single bundle where it has to be applied.

• ##### Re: What am I missing?

Your message is awaiting moderation. Thank you for participating in the discussion.

@srini
nice article

@Rob
Yeah i know exactly what you mean by "what the fuss is about".
From my experiences 80% of these Spring/Hibernate/AOP/DI/TDD/CI/insert-your-favorite-buzzword/etc projects don't need
DDD, it's just CRUD stuff.

As Eric Evans told me, DDD is for the 10%-20% percent of a system -> the truely complicated sh*t.
That logic should be implemented by developers with strong design skills with the help of open minded business analyst -> DDD is a sophisticated
technique for that.

My point is people tend to "ddd"-everthing, i.e.
if anyone tells you: "yeah our system is completely build upon/using DDD".....yeah ok, dream on

None the less i think DDD is great stuff and definitely changes your view of perspective on design/oo/teamwork.

Cheers
Phatthana

• ##### It *completely* misses the point...

by Ronald Miura,

Your message is awaiting moderation. Thank you for participating in the discussion.

It seems that the author thinks a 'rich domain' is just 'inject DAOs into hibernate-mapped objects'...

Looking at the source code, you can see the domain is just the plain old anemic model, with DAOs (disguised as Repositories) injected.

At least in the examples, it doesn't make sense to use an instance of an entity to 'find' others, which don't even have any relation (but its class) to the first. It is just being used as a Repository (yeah, 'loan.add(newLoan)' IS stupid). And the domain logic, which should be inside the entities, are externalized to the services, which are just glorified procedures.

Where is the 'insight'? Where is the 'objects model the business'? Where is the 'ubiquitous language'?

If you are looking for a DDD example, take a look at the TimeAndMoney (timeandmoney.domainlanguage.com/) library. No, it doesn't have a 'persistence layer', but DDD is not about these, it's about capturing the business into objects. It isn't about CRUD, it's about creating a language in code that matches the language in business (the core of it). It's not about DI or Spring or Hibernate, it's about good, careful, insightful, relentless design.

• ##### Re: It *completely* misses the point...

by Dustin Woods,

Your message is awaiting moderation. Thank you for participating in the discussion.

If you are looking for a DDD example, take a look at the TimeAndMoney (timeandmoney.domainlanguage.com/) library. No, it doesn't have a 'persistence layer', but DDD is not about these, it's about capturing the business into objects. It isn't about CRUD, it's about creating a language in code that matches the language in business (the core of it). It's not about DI or Spring or Hibernate, it's about good, careful, insightful, relentless design.

"TimeAndMoney" makes a nice example of a library but it is far from any help at all when building an entire application. I personally appreciate samples like these because is shows the struggle that people have trying to apply DDD to real world problems. Without seeing samples that have gotten the blessing of being DDD maybe DDD is for small libraries only and doesn't apply to real world problems. It's easy to criticize Srini for sharing an interpretation of DDD without opening yourself up to criticism with any sample of your own.

• ##### Re: It *completely* misses the point... Not!

by Geert Pante,

Your message is awaiting moderation. Thank you for participating in the discussion.

If you are looking for a DDD example, take a look at the TimeAndMoney (timeandmoney.domainlanguage.com/) library. No, it doesn't have a 'persistence layer', but DDD is not about these, it's about capturing the business into objects. It isn't about CRUD, it's about creating a language in code that matches the language in business (the core of it). It's not about DI or Spring or Hibernate, it's about good, careful, insightful, relentless design.

"TimeAndMoney" makes a nice example of a library but it is far from any help at all when building an entire application. I personally appreciate samples like these because is shows the struggle that people have trying to apply DDD to real world problems. Without seeing samples that have gotten the blessing of being DDD maybe DDD is for small libraries only and doesn't apply to real world problems. It's easy to criticize Srini for sharing an interpretation of DDD without opening yourself up to criticism with any sample of your own.

Hear, hear!

Having fooled around a bit myself with DDD and Java, I hoped to find a way to do three things at once. Do DDD, avoid having to write a lot of duplicate boiler plate code, and keep Spring/Hibernate/JUnit best practices. In doing so, I independently did the same discovery as mr. Laddad: that AOP could be the missing link.

Indeed, Domain Driven Design is not tied to particular use of any framework, but if Hibernate allows you to auto-generate DAO's and Repositories, and Spring's @Configurable annotations with AOP allows you to auto-generate Factories, why wouldn't you go with the flow?

Srini, I haven't checked your sample code thoroughly, but if you managed to get it all connected and working, you did an excellent job, and it could provide the basis of a lot of our future projects' designs.

• ##### Re: No asserts in the tests

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Peter, the unit tests for repository classes in the sample application have asserts inside test methods, but you are right, the other test classes like LoanDomainTest should have assert statements to verify state and behavior of domain objects. Also, if you are not already using them, check out the additional assert's available in JUnit 4.4 version (Hamcrest asserts) that add a great value to write and understand the assert logic in test methods. The other unit testing guideline (which is a given to TDD followers) I try to follow is: No log.debug() or log.error() method calls in the test classes, these should be replaced by appropriate assert statements.

• ##### It's Great

by Ravi Koda,

Your message is awaiting moderation. Thank you for participating in the discussion.

Thanks srini , This is what i am looking for my project.

Regards
Ravi

• ##### Re: Mixed feelings

Your message is awaiting moderation. Thank you for participating in the discussion.

A lot of people have mentioned the presence of CRUD methods on entities. I think this is a fairly fundamental and very important aspect of DDD. The standard reference by Eric Evans specifically states that you should not so this, and for a very good reason - it violates OO design principles. A class should have one responsibility - persistence is not the responsibility of an entity. While it farms the work out to a repository, an object's interface is just as important to defining its responsibilities as the actual implementation.

It is extremely important that when undertaking this approach, the principle are kept in mind and adhered to, as there are pitfalls waiting around the corner for those who don't.

As far as this being more an anaemic model, it is just because of the lack of hard core business logic, and in itself isn't a problem. I don't see a problem with creating an anaemic model from a DDD focus - at least the focus remains on the ubiquitous language.

I have just been involved in rescuing an SOA development. SOA services can be equated to Eric Evans' idea of an application service. This is essentially a gateway into the business logic, or the domain model. The development in question used JAXB to generate classes from an xsd defining the service interface, and to populate objects from the xml message. The services were extremely long, procedural, untestable methods which utilised the generated classes. There was a layer of DAOs which also used these generated classes!! Something to shift focus onto the domain and reinforce the fact that the SOA service is a thin layer whose responsibility is integration - not business logic, would have avoided this.

I find it perplexing the number of SOA oriented developers who dismiss the idea of a rich domain model. It seems to me to highlight a lack of understanding of the very essence of the architecture they are implementing. These two approaches are not mutually exclusive - there are distinct responsibilities in each layer.

Anyway, sorry about the waffle. This is my first post - hi everyone :)

• ##### Domain-Obects Java Classes not so intuitive

Your message is awaiting moderation. Thank you for participating in the discussion.

Article is great in promoting Domain Driven Design, but the sample application code does not express the domain concepts in java objects so well. For example, typically if there were no automation, a bank which offers loans would typically have a LoanRegister (a loan folder where each loan offered to a borrower is a page) for adding loans, updating loan info etc., So as per my tastes, I would prefer to have a LoanRegister class on which methods like addLoan(Loan), updateLoan(Loan) are exposed.

• ##### Re: Mixed feelings

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Yuriy, In the sample code, I wanted to show that the Entity objects are first-class citizens in the domain model, they should also take care of the persisting the object's state (by calling a repository or a DAO behind the scenes). Hence the call to the (wired) Loan entity object to add a new loan record. You definitely want to use the domain object that has been associated with DAO and other persistence resources (Hibernate SessionFactory etc) for creating and updating the domain objects. In the example, I could have set the loan data in loan object itself and then call loan.add() method w/o any input arguments (in which case, the domain would act on its own instance).

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Laurence, Domain objects should also be responsible for persisting the data (CRUD) in addition to encapsulating the state and behavior of business domain entities and the business logic. This way, clients can call the domain objects directly to create and manipulate the domain state instead of relying on DAO's (which are infrastructure related classes in my opinion) to take care of the persistence. Repositories, just like Entities, are domain objects that are there for a purpose (of hiding the DAO implementation details behind the repository classes). It's not always required for the Entities to call Repositories for CRUD functions. You mention Aggregates and Services, these domain elements also have their own characteristics on when to use them in domain model implementation. Eric Evans book is the best source for learning more about all these domain elements.

• ##### Re: It's wonderful!

by James Bao,

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Srini, I disagree with you that persistence is the responsibility of Domain objects. Stripping out the data persisting logic from the domain object will make the code more readable and maintainable.

• ##### Re: Mixed feelings

Your message is awaiting moderation. Thank you for participating in the discussion.

Another argument against having Persistence CRUD in domain objects is that you have a circular dependency between "domain" and "repository" sub-packages. Circular dependency is never a good thing regardless what kind of xDD you are practicing.

• ##### Re: Mixed feelings

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Yuriy,

I don't agree with you here. Circular dependencies just signify poor design. You can quite legitimately have a domain object deal with persistence without circular references. Note, a domain object which is an entiy should not be responsible for it's own persistence, a repository object should (Not a DAO - this is rooted in deficiencies of EJB).

The underlying priciple is that the domain model is supposed to be a model of your business. Does it make sense within that domain that you need to store and retrieve entities (say, a loan). Absolutely yes, so this should be handled by a domain object. When you do store a loan in the real world, do you get the loan to do it? No, you stick it in some sort of repository. You can see here, the domain model is modelling the real world.

Typically, as per good design practice, the repository will be comprise an implementation and an interface. All domain type references are confined to the domain layer (model).

The repository will then farm off the technology specific aspects to an object in the infrastructure layer. This can be achieved through extension, delegation, template pattern etc. Whatever way you choose, avoiding cirulcar references is just down to good design.

Typically in a hibernate environment for example, you would have a generic persistence object, or a base persistence object for instance, which takes a class type and an object. Though not really correct, but in line with many codebases, let's call this the HibernateGenericDao class. It implements the interface GenericDao which defines the method "add(String className, Object value)". In the domain model, we have a LoanRepositoryImpl class which wraps GenericDao and implements LoanRepository. LoanRepository defines the method add(Loan loan). The LoanRepositoryImpl.add(Loan loan) implementation delegates to genericDao.add(Loan.getClass().getName(), loan). The HibernateGenericDao then takes care of the hibernate specifics.

LoanRepository, Loan and LoanRepositoryImpl are members of the domain layer. GenericDao and HibernateGenericDao are in the infrastructure layer. The domain layer knows about the infrastructure layer, but the infrastructure layer knows nothing of the domain layer. Perfectly layered, no circular references. If we want to change the persistence mechanism, we plug in a different implementation of GenericDao into LoanRepositoryImpl.

Then, when we want to add a loan, a ui object may collect the details, an application service object collates the details into a loan object, and call loanRepository.add(loan). I don't see what is not clear about this implementation where persistence is handled by a domain object.

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

Persistence is absolutely the resposibility of a domain object - though an entity is not responsible for its own persistence. (see my next post) This distinction between a domain object and an entity object is crucial.

Your message is awaiting moderation. Thank you for participating in the discussion.

The sample app in this article has little to do with DDD. Chris Richardson's aop-ood is a way better in that sense.

• ##### Re: What am I missing?

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Rob, In the sample application I focused more on the domain injection capabilities offered by Spring framework and the role AOP in DDD. I agree with you that the Entity objects should have more business logic than what the sample application shows. Also, the method to get the list of ProductRate Value Object's should be in a Repository rather than the Value Object itself.

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi James, if persistence is not the responsibility of Domain objects, where would CRUD logic be handled? We don't want the clients to be calling DAO classes directly, they should be ideally calling some business object which fronts the DAO because data access logic, in my opinion, is an infrastructure concern that the client shouldn't know anything about.

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Srini,

I really think having repositories and an infrastructure layer, and dao's and a data access layer is a massive overcomplication of a simple problem. As far as why persistence belongs in the domain model (re your reply to James), the simple explanation somes from the domain we are trying to model. Given a traditional paper based office, we have a new client say, we collect their details (at least enough to identify them), we create some sort of file for them, then we store them in a repository of some sort, organised in such a way that we can easily retrieve those details. This obviates the necessity for a repository in the domain layer.

The repository should farm off technical aspects of the persistence to an object in the infratructure layer. There is no need for DAO's, or a data access layer. Data access layers are all about removing that functionality from the domain, which is specifically what we do not want to do. DAO's only came into being because of the shortcomings of the EJB spec. Nobody uses Entity EJB's anymore, so please stop using DAO's.

• ##### DDD on 3 tiers (Differents JVM)

by iury ribeiro,

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Srini,

Great discussion! I enjoyed a lot.

I would like to clarify the following case:

As you said that the CRUD methods belong to entity objects(domain object)and to get the others objects through the navigation, So I released in the case where the application is split on 2 JVM accessing a stateless session bean, We need to convert ours POJO on Proxy Pojo to access the facede session.

Am I right?

Regards,

Iury

• ##### Sculptor

Your message is awaiting moderation. Thank you for participating in the discussion.

Nice article! Looking for a tool that supports this type of design? Take a look at Sculptor...

Sculptor is an Open Source tool that applies the concepts from Domain-Driven Design and Domain Specific Languages.

You express your design intent in a textual specification, from which Sculptor generates high quality Java code and configuration. Sculptor takes care of the technical details, the tedious repetitive work, and let you focus on delivering more business value – and have more fun.

The generated code is based on well-known frameworks, such as Spring Framework, Spring Web Flow, JSF, Hibernate and Java EE.

The DSL and the code generation drives the development and is not a one time shot. It is an iterative process, which can be combined with Test Driven Development and evolutionary design.

Sculptor home: fornax-platform.org/cp/x/aAQ

• ##### Re: It's wonderful!

by iury ribeiro,

Your message is awaiting moderation. Thank you for participating in the discussion.

Hello Lindsay,

May you clarify my question?

In the following case: where the application is split on 2 (tomcat and jee server) JVM accessing a stateless session bean, We need to convert ours POJO on Proxy to access the facade session. Am I right?

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Iury,

I'm not entirely clear on exactly what it is you need to do, but I'll take a guess and put something forward.

Typically, our front end will call a SLSB Facade on tier 2. The traditional, and still somewhat sensible way of doing this is implementing an application service via the SLSB. If for instance we want to get a Loan object, tier 1 would call the tier 2 SLSB application service. The application service would have access to the domain model, querying the LoanRepository to find the required Loan object and passing it back.

This type of arrangement allows you to incorporate an SOA implementation alongside the rich domain model. The SLSBs can be thought of as gateways to the model.

• ##### Re: DDD on 3 tiers (Differents JVM)

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Iury, Sorry for the delayed reply. DDD design and development concepts remain valid even if you are architecting your application as a 2-tier or multi-tier application. Domain objects live (at run-time) behind the facade layer (implemented using stateless session beans or POJO's). One thing to keep in mind (if you have a choice) is to work on the domain layer first to capture the business logic, business rules, persistence etc first and then work on the facade classes which should be just proxy classes to the domain layer (i.e. they shouldn't have business logic, only the orchestrate type of logic).

• ##### Re: Sculptor

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Patrik, Thanks for info on Sculptor. It looks very interesting. I am currently working on a research project on DDD and Code Generation topic and I have been looking OpenArchitectureWare tool for code generation and MDA purposes. Sculptor has Hibernate and Spring integration which is very coo. I will read about it in more detail and check with you if I have any questions.

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

Can you explain the difference between an entity object and a domain object?

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Mattias, Entity object is a type of domain object (Value Object, Service, Repository etc being the other types). I use the terms and definitions covered in Eric Evans' book Domain Driven Design.

• ##### Naming throwing

Your message is awaiting moderation. Thank you for participating in the discussion.

I got confuse if the idea was give a real example of DDD or just throw all the tools and practices names.

Do you really need all these tools to develop a DDD application?

• ##### Re: I *completely* agree

Your message is awaiting moderation. Thank you for participating in the discussion.

The article declares the anemic model as an anti-pattern (is it really?) but then, if you look at the source, implements the "rich domain objects" as Entities + embedded DAOs.

• ##### Re: Naming throwing

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Eduardo, It's not the intention of this article to suggest that every business domain out there in the real world requires all the tools and techniques mentioned in the article. If OOP by itself can represent a business domain and support DDD adequately then no other tools are needed for implementing such a domain. But after working on few domain implementation projects (of various sizes and scopes), I found that other techniques such as DI and AOP can complement OOP in addressing the business domain requirements especially in terms of persistence, transaction management and application security. If you could share your thoughts and experiences on what tools you used in implementing domain driven design projects, that would be great.

• ##### Re: I *completely* agree

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Dimitris, From my experience after working on few J2EE projects involving different sizes of business domains, I found that anemic model is an anti-pattern to DDD implementation. Most of J2EE developers are still designing the applications with a stateless session bean (facade) that has all the business logic and leaving the domain objects (Entities) with just getters/setters. Can you elaborate more on why you think anemic model is not an anti-pattern? I am thinking may be there are some use cases where anemic model makes sense, but I am curious know more about those use cases. Regarding the sample application, I spent more time in focusing on how to use DI and AOP in a DDD application. You are right, in a real-world DDD application, Entities which should have lot more business logic and domain state manipulation logic than what's included in the code examples.

• ##### Re: What about the Grails approach?

by Soner Dastan,

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Srini. First of all thanks for this good article.
I read several articles about DDD but still I could not find out, when to use the DDD approach
makes sense and why the "anemic" principle is an anti-pattern. I can not see that using the anemic model causes issues to call it an anti-pattern.
In the anemic model we also have the separation of responsibilities and so on.
What are the differences except that the domain model in case of DDD includes business logic?
Both models has a similar architecture layering.

Is there an article comparing both approaches with their pro and contras and showing sample use cases where which design style should be used?

• ##### Re: What about the Grails approach?

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Soner, Thanks for the comments on the article. The main principle that I learned from using DDD in my projects is that Domain comes first and Infrastructure comes second. With this philosophy, I have seen a big difference in how I and other developers approach the design and coding tasks. Regarding the resources for DDD, the best place is to start is Domain Driven Design website. Also, feel free to post this question on DDD yahoo group which is a great forum to discuss DDD related questions and ideas.

• ##### DDD and agile

by Nima n,

Your message is awaiting moderation. Thank you for participating in the discussion.

agile methodology use user story for gathering requirement, what is user story role in domain driven design?

• ##### Re: DDD and agile

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Nima, Agile methodologies is a better fit for DDD implementation in the sense that Agile methodologies encourage iterative and incremental development. Modeling, design, development, and unit testing phases in a DDD project are best done using the Agile and Iterative approach.

• ##### Domain objects should not call CURD operations

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Srini,
Article's starting was good and even i sent this link to my friends saying great implementation for DDD. But when we saw the code in the domain entities method you are calling CURD operation which smells some wrong implementation. You are neglecting basic rule of domain driven design which says that your domain should be persistance ignorent.

Please let me know if my understanding is wrong. What should is say to my friends whome i sent this link .

• ##### Re: Mixed feelings

by H S,

Your message is awaiting moderation. Thank you for participating in the discussion.

Srini,
First thanks a lot for good article. I followed through your article and reviews of different people.

I still have one question (as Lindsay said) and you also agreed that persistence should be the responsibility of the repository rather than the entity. We need one domain object which would be acting as a (service) creating a entity and persisting the entity to DB.
e.g
loanRepository.save(newLoan)
Which domain object will you add this kind of behavior, and do we require such domain object for each entity in our domain?

• ##### don't inject repository into model

by Peng Sunny,

Your message is awaiting moderation. Thank you for participating in the discussion.

the sample is not perfect, don't inject any technology into business model, decouple "What" from "How". we can use Domain Events pattern to do communication with them. all these have implemented in my famework(DDD framework for Java) jdon.dev.java.net

• ##### Re: Not even close to DDD

by 李 引,

Your message is awaiting moderation. Thank you for participating in the discussion.

eclipse aspectj can worked in osgi style.

• ##### Domain Layer uses the Infrastructure Layer. The layer below it.

by Roy Oliver,

Your message is awaiting moderation. Thank you for participating in the discussion.

I am highly confused by the implementations I'm seeing all over the net. Recall this? www.herrodius.com/blog/wp-content/uploads/2010/... - Eric's Layered Architecture? The domain layer uses the infrastructure layer and has the ability to inherit objects from it. Not the other way around. Did I read it wrong? Why are projects referencing the domain layer from the infrastructure layer? That seems to be a direct violation of DDD.

Could some of you attempt to explain this?

I'm seriously confused.

• ##### A comment on the sample application

Your message is awaiting moderation. Thank you for participating in the discussion.

I found DDD interesting, but I also think that Object Oriented Programming is DDD by definition. And with this in mind, I don't understand why the domain objects in the sample application are full of getters and setters and without any interesting behaviour. Probably the implemented requirements are too simple and that does not help to create a rich object model ? The process loan funding might have an interesting business logic that, from my understanding, should be modeled in your domain objects, rather than in a service method. I have posted an example related with object oriented design here: www.copypasteisforword.com/notes/object-oriente....

• ##### Re: It's wonderful!

Your message is awaiting moderation. Thank you for participating in the discussion.

Great!

• ##### Very bad example application, practically anti-DDD example

by Georgi Danov,

Your message is awaiting moderation. Thank you for participating in the discussion.

I was going to read the article, but colleague showed me the sample application first. The sample application is total s**t and has nothing to do with DDD so I am totally not going to waste my time reading the article. Read the book man...

• ##### Re: Very bad example application, practically anti-DDD example

by Roman Tmk,

Your message is awaiting moderation. Thank you for participating in the discussion.

When saying that something is not good, you should point out what exactly you disagree with, otherwise your comment has no meaning.

• ##### DDD Modeling tool set

Your message is awaiting moderation. Thank you for participating in the discussion.

Is there a specific modeling/mapping tool to use for domain driven design? Preferably free.

• ##### Re: It *completely* misses the point...

by Ronald Miura,

Your message is awaiting moderation. Thank you for participating in the discussion.

Oh, past me... why? WHY?...

• ##### JBoss Business Rules (Drools)

Your message is awaiting moderation. Thank you for participating in the discussion.

Can you explain a little more what you meant by this sentence: "A good design is to place all the rules (especially complex rules that change frequently as the business strategy changes) into a Rules Engine and invoke them from the domain classes."

Aren't the rules separated from the domain classes in a rules engine? I get a lot of questions about performance and flat vs. hierarchical model structure; that flat performs better than hierarchical. How someone using a rules engine continue to adhere to DDD principles and still manage to handle significant load in a rules engine like JBRMS (now Decision Manager)?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p