Book: "Domain driven design" implemented in Spring

[josenyimi]

Still struggling where to put logic ?
I hope this read may help:
http://www.springframework.org/node/97

The responsability of
Presentation Layer
Business Layer
Persistence Layer
Domain Layer
Is well explained there.

Important note is that the domain layer is a "cross-layer" layer (not just a layer on top of another layer).

Quote:
"The business layer should be responsible for the following:
* Handling application business logic and business validation
* Managing transactions
* Allowing interfaces for interaction with other layers
* Managing dependencies between business level objects
* Adding flexibility between the presentation and the persistence layer so they do not directly communicate with each other
* Exposing a context to the business layer from the presentation layer to obtain business services
* Managing implementations from the business logic to the persistence layer"

Quote:
"... The domain object layer consists of objects that represent real-world business objects such as an Order, OrderLineItem, Product, and so on ..."


HTH,
José.

[rebornspirit]

That is what I meant with my previous post! Its VERY easy to explain a layered architecture using a hello world example just like in the link provided in the previous post.

BUT ... there is a BIG difference between a hello world and real life examples. Real life examples just are much more complicated with much more complicated dependencies and much much more difficult business logic.

So I think books like DDD are very interesting to read because he explains why he does something using real life enterprise problems ...

For example the article doesn't mention are warn you for the Anemic model, and that should be the key in the article. Does it mention where the domain related logic goes, does it mention were the domain related logic goes that had dependencies with other interfaces....

Anyways thanks for the article ... it proves that we should be elvolving in two kinds of article:
- hello world
- people who tell their story about there enterprise project

Grtz

[JuanZe]

I want to add my own ideas about the subject of this post... sorry if my english isn't good

I think you mean a service layer when you say use-case layer. Service layer shouldn`t contain much logic and the service layer is the place to add transaction/security. If you need to combine different services to create a new piece of functionality, this new peace of functionality also is a service. And if those other 'lower' services only are called from 'higher' services, I think it is questionable if those lower services should be called service.

I agree with the higher & lower services approach.

I prefer the term "service" for the higher services (a facade that deals with transaction/security issues, one for each client of the application), and the term "manager" (or "controller" or "administrator") for those other lower services. The managers are derived from DDD concept of Modules. I think that Aggregates are the key...

My analysis follow this path:
. identify and demark boundaries of Aggregates
. each aggregate lead us to determine the necessity of a Manager to handle logic cohesive and internal to the aggregate (that can't be solved by domain objects itself)
. the Aggregate/Manager also determine the necessity of a Repository
. at this point, we have at hands a subset of domain objects with a repository and a manager, and a Module emerge...

So, Aggregates are good starting point to define lower services, repositories and modules. This approach not cover all cases, but is really useful to me.

I used to work with an analogous approach, and Eric's book give me a really useful insight to refine it and get this one.

I'm still learning and finding better ways to improve our process. But I think Spring framework + Hibernate + DDD can lead us to projects with clean and pure domain models put to work with POJOs.

J.

[Ben Alex]

In examples I almost never write access modifiers, but in most cases these methodes are public.

I take a different approach. In my domain objects I generally provide public getters, public setters if the property is not "state managed", and actual methods for modifying "state managed" properties, like fireEmployee(). Now if fireEmployee() should only be called as part of a transaction-controlled workflow, I use access modifiers to make it package protected. I put the services layer in the same package as the domain object. Sometimes we need state managed methods to be callable by other domain objects, like a BankAccount that has a changeBalance() method (because balance is "state managed") that accepts a Posting. Because Posting and BankAccount are different "aggregates" (as per DDD terminology - a very useful pattern in teaching people this stuff I find) we need an intermediate object for passing the Posting to the now-forced to be public BankAccount.changeBalance() method. So we create a posting.BalanceChangeRequest, providing a package protected constructor that accepts the Posting. The BankAccount.post() only accepts a BalanceChangeRequest. Thus you've effectively used access modifiers to extend package protection to the Posting package. I also use Hibernate field-level access, and overall it all works pretty nicely.

On the subject of reusing domain objects for DTOs and web form backing objects, I've found it not worth the hassle. Such form backing objects / DTOs can be created in seconds as they're just simple JavaBeans. It's more important to have a rich domain model that is infrastructure independent.

[cepage]

On the subject of reusing domain objects for DTOs and web form backing objects, I've found it not worth the hassle. Such form backing objects / DTOs can be created in seconds as they're just simple JavaBeans. It's more important to have a rich domain model that is infrastructure independent.

Hear, hear! I agree 100%. I'm glad that a member of the Spring team is expressing this opinion. I thought that reusing your domain objects in the web tier was being pushed as a Spring best practice.

[sethladd]

On the subject of reusing domain objects for DTOs and web form backing objects, I've found it not worth the hassle. Such form backing objects / DTOs can be created in seconds as they're just simple JavaBeans. It's more important to have a rich domain model that is infrastructure independent.

I agree with this statement as well, except I certainly don't think it's a best practice to always create DTOs for web form backing objects.

The ability to use a domain object to back a web form is one of the reasons I love Spring. But probably what I love more is that I have the choice to do it. With Struts I don't have that choice.

[Alarmnummer]

I agree with this statement as well, except I certainly don't think it's a best practice to always create DTOs for web form backing objects.

I also agree. Binding directly on your domain objects is terrible for the design. Try binding on value objects (that are immutable). I hate it..

Domain objects in the weblayer totally screw up your objects.

[colinchalmers]

Interesting discussion and in line with my thoughts concerning the layered approach.

One thing I am (repeatedly) running up against is the mix of domain Objects and database mapping (objects).

Let me explain:

Far too often I see the approach that apps are built from the database up, whereby the Objects used to map to tables are used as domain objects. Although this may be appropriate in some cases where the database is normalised to the extent that it mirrors the actual domain model, in many circumstances it's not appropriate. Furthermore these *domain* objects are often without behaviour whereby they resemble DTO's more than actual domain objects.

I recently posted a question releating to the use of OpenSession (hibernate) in view layer and whether this was good practise? Again using lazy-read limits overhead the idea of always throwing hibernate objects into my templates doesn't feel right.

What do others think?

Colin

[rebornspirit]

A project I'm working on now is showing bad signs of using domain objects in the web layer, let me explain.

We are using hibernate with most of the relationships defined as lazy which causes sometimes LazyInitExceptions in the web layer.
Also be aware of the Hibernate dirty check, I've seen too many developers that need to shown some domain obejt data on the screen, but in a certain case certain field of the domain object should have a different value to be shown on the screen. So they change the domain object to show the correct data on the screen (but ofcoarse this data should NOT be persisted). What happens a few steps later is that when Hibernate is flushing its session, its seeing that domaoin object as changed and it will be persisted.

So I agree that creating DTO's is a small effort but can help avoid multiple problems.

Question:
In a layered architecture, where do you create the dto's, for example when I have the following layer

DAO
--------
Domain
--------
Manager
--------
Service
--------
MVC Controller

I gues the service layer, so that when switching to for example to Swing, you can reuse those services with the existing dto's.


Question:
What are you using to map the dto's with the hibernate domain object data?

[sethladd]

shown on the screen. So they change the domain object to show the correct data on the screen (but ofcoarse this data should NOT be persisted). What happens a few steps later is that when Hibernate is flushing its session, its seeing that domaoin object as changed and it will be persisted.

That's just a horrible practice. If you need different values, then you introduce a DTO specific to the view. It's not a fault of Hibernate or the layering that the developers are changing values on your domain objects for the view.

Being able to move your domain objects around layers is a good thing, I believe. At least you have the choice to do it.