Article: Domain Driven Design and Development In Practice

by Niclas Nilsson on Jun 16, 2008 |

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:

  • Business Rules
  • 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.

Related Editorial

Hello stranger!

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

Get the most out of the InfoQ experience.

Tell us what you think

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

Email me replies to any of my messages in this thread
Community comments

It's wonderful! by Geng Laurence

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. by Leonard Petrica

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.
public void add() {
loanRepository.add(this);
}

No asserts in the tests by Peter Bona

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 by Yuriy Zubarev

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.



What's the advantage of
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! by Geng Laurence

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! by Srini Penchikala

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

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 by Kaushik Selvaraj

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? by Phatthana Sitthideth

@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

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


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


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 by Srini Penchikala

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

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

Regards
Ravi

Re: Mixed feelings by Lindsay Holman

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 by venkataramana madugundu

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 by Srini Penchikala

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! by Srini Penchikala

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

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 by Yuriy Zubarev

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 by Lindsay Holman

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! by Lindsay Holman

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.

Misleading by Ilya Boyandin

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? by Srini Penchikala

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! by Srini Penchikala

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! by Lindsay Holman

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

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 by Patrik Nordwall

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

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! by Lindsay Holman

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) by Srini Penchikala

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 by Srini Penchikala

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! by Mattias Fagerström

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

Re: It's wonderful! by Srini Penchikala

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 by Eduardo Miranda

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 by Dimitris Menounos

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 by Srini Penchikala

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 by Srini Penchikala

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.

What about the Grails approach? by Goran Oberg

Thanks for a good article. I have used JPA and the standard DAO approach in a couple of projects (not DDD but still an OK approach), but I'm now involved a Grails based project and that have definitely made me to take a more serious interest in DDD.



What I like about Grails and more specifically the GORM, is the domain centric approach to data access. No daos and no repositories to be implemented, just plain domain classes! A dynamic language like Groovy giving the possibility to constructs like User.findAllByNameAndTimeBetween(name,start,end) without implementing the finder method (dynamically created), just adds to the plus side.



Of course Grails have downsides as well (some of them quite serious to), but it will not stop me from using Grails on certain projects and it will definitely give me some architectural inspiration when I'm back on my next Spring-hibernate project.



Just a small comment on the source code in the article:



Shouldn't finder related methods be static and operations like save act on the object it self?

Re: What about the Grails approach? by Soner Dastan

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? by Srini Penchikala

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

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

Re: DDD and agile by Srini Penchikala

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 by Sandeep akhare

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

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
Loan newLoan = CreateLoanWithBusinessRequirements()
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

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 李 引

eclipse aspectj can worked in osgi style.

Domain Layer uses the Infrastructure Layer. The layer below it. by Roy Oliver

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 by Enrique Molinari

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! by Felipe Guarneri

Great!

Very bad example application, practically anti-DDD example by Georgi Danov

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

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

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

52 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy