Book: "Domain driven design" implemented in Spring

Quote:

---

Originally Posted by rebornspirit

Thanks for the reply,

I always thought when you were talking about the domain layer that you where talking about something above the domain model, but know I see that the term domain model and domain layer are the same... sometimes mixed terminologie can lead also to misunderstanding.

---

This is true and with enterprise applications it irritates me quite a lot.

Quote:

---

Code:

---

class Employee{

  void setSalary(int amount){
        Validator validator = ... retrieve salary validator
        validator.validate(amount);
        _amount = amount;
  }
}

---

I agree that this is the best way, the problem is that Spring has no nice way to handle this and I cannot use the solution in the sandbox.

So I guess that you would move the validation to the service, corect?

---

Personally I would use the ServiceLocator to get my dependencies. Your design won`t be damaged as much as the anemic domain model (putting all the logic in service-like objects).

A few thoughts (I`m reading DDD and PEAA):

The term Service object is used in different context. With Patterns of Enterprise Application Architecture it is a facade for your domain layer, that coordinates transactions/security but doesn`t do anything else (it doesn`t contain any logic)

In Domain Driven Design you have (at least) 2 types of Service objects:
ApplicationService objects.
DomainService objects.

A Service object in DDD is an object that only has logic that shouldn`t be part of the entities (sometimes your objects can get very bloated and it is better to group the logic instead of scattering it over a lot of domain objects). But DDD-Service objects are part of the Layer and don`t sit on top of it. The difference between a Application Service Object and a Domain Service Object is that the Application Service object contains application logic, but the Application Service Object will forward the call to objects in the Domain Layer eventually.. adding extra domain logic).

Personally I would like to drop the name 'Service object' from DDD and replace it with Manager object (if you know something better I would be happy to accept it). In your case you have a lot of objects that combine logic from other objects to create new functions and I would call these object: Managers.

And you also have a boundary for the rest of your system (your gui for example) and these boundries I would call services.

If someone else (with more insight than I have) has some ideas about this subject, please reply :) Enterprise problems are difficult enough, but creating so many names for the same thing, or one name for thing that have a different meaning (depending on who said it) doesn`t make it any easier. It would be nice if someone wrote a nice article about the unification of PEAA en DDD.

Quote:

---

Originally Posted by Alarmnummer

Example:

Code:

---

class Employee{
  void fire(){
        Desk desk = getDesk();
        desk.clean();
        setStatus(FIRED);
        setSalary(0);
        setFiredDate(new Date());
        employeeDao.save(employee); //this one is questionable.
    }
}

---

---

And if "fire" logic is put inside Employee domain object, then transaction demarcation should take place inside EmployeeService object that coordinates/delegates call to this domain object's method, right?

But since good practice is reusing domain objects in UI layer, thus avoiding DTOs for that, that means someone in UI layer could easily call this Employee.fire() method in that layer, which is dangerous since it is out of transaction? In example above it wouldn't be possible since it is not public method, but I guess you would have to have some of these methods being public if you want to delegate calls to them from services in different packages?

-Vjeran

Quote:

---

Originally Posted by Alarmnummer

Enterprise problems are difficult enough, but creating so many names for the same thing, or one name for thing that have a different meaning (depending on who said it) doesn`t make it any easier. It would be nice if someone wrote a nice article about the unification of PEAA en DDD.

---

:-)))
So much about UBIQUITOUS LANGUAGE heavily propagated by DDD, when even Evans and Fowler can't practice it between themselves! ;)

Quote:

---

Originally Posted by vmarcinko

And if "fire" logic is put inside Employee domain object, then transaction demarcation should take place inside EmployeeService object that coordinates/delegates call to this domain object's method, right?

---

It should be in the Martin-Fowler-EmployeeService object. Not in the DDD-EmployeeService object ;)

Quote:

---

But since good practice is reusing domain objects in UI layer, thus avoiding DTOs for that, that means someone in UI layer could easily call this Employee.fire() method in that layer, which is dangerous since it is out of transaction?

---

Yes.

Quote:

---

In example above it wouldn't be possible since it is not public method, but I guess you would have to have some of these methods being public if you want to delegate calls to them from services in different packages?

---

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

So we can conculde that it is just hard work making good software!

Quote:

---

But since good practice is reusing domain objects in UI layer, thus avoiding DTOs for that, that means someone in UI layer could easily call this Employee.fire() method in that layer, which is dangerous since it is out of transaction?

---

I think you have to make a choose:

1. anemic model + domain model in view
2. smart domain model + dto's

1.
---
So or you work with the anemic model, in that case you will not have any problems using the domain objects in the view. We are working this way now (not by choice). And I have some issues with that:

- We have implemented our persistence using Hibernate but using lazy initialization and the domain object in the view sometimes causes extra work not to get a lazyInitException.
- Most of the time data that should be showed on the view can be represented by the domain object. But there are cases in which we like to show a list of domain objects on the view ... BUT some domain object fields should be replaced by another value under certain conditions ... we cannot simply modify the particular domain object field that needs to be shown because with the next Hibernate flush Hibernate thinks the domain object has changed and it will be persisted. So for those cases we still need dto's.
- When you start putting logic into your anemic model... suddely your view can access that logic and who nows what happens then ;)

So... we have a second solution

2.
---
We could throw away the anemic model (which a prefer) and start to create well designed smart domain model. I would then let the domain model go as far as the controller, and it is the mvc controller's task to create a dto. Some thoughts:
- I agree that dto's need to be maintained, if your domain model changes, yout dto needs to change too.
- Perhaps a nice framework should be used to do the mapping or perhaps it can be done by hand... no experience in that.. but will give it a thought.
- No more Hibernate LazyInitException in my view when using dto's
- No more spooky object updates during a flush because someone has accidently modified something in the domaon object to show it as read only in the view
- you are sure that NO DOMAIN LOGIC can be called from the view! I would not like to go to projects where people put all kind of business logic into jsp tags causing not only unmaintainable code but mostly excessive use of database connections :)
- I think that is a nice role for the mvc controller, receive data from the service and map it to a view object.
- For those developers who only make layouts / views all day long and are not concerned about business logic that appears behind the scenes, those dto's ar emucg more clear to work with then a complex domain object grapgh in which he is not interested. (for example a view that needs data from 10 domain objects is probly for a gui designer harder to figure out than to give him a dto with just those 10 fields on it)

But I have to admit that I'm just a junior developer (3.5y experience) so I'm still in the learning process ;)

But I think its harder for people who for example get right from school and need to start developing layered architecture and have to make GOOD domain models, after 3.5 years it is still hard ... but sometimes there is a little light at the end of the tunnel that keeps us going on ;)

I think we are in need of more professionel people sharing there experience, people who have seen projects fail or succeed for certian reasons... that informations should be gathered on a site that keeps track of these things and give us good discussions ... so that when we start a new project we can learn from other peoples mistakes instead of reinventing the wheel and making the same mistake. Actually I expected more feedback from the Spring guru's on these forums. Or are tehy in the dark when we are talking about there anemic model approach ... because I think that is one of the Spring weaknesses for now.

But even in were I work now there is some people who like job protection just too much ... its a too bad ... software developemt is a dificult topic, the world would be a better place if we would all help each other out ... *whishfull thinking*

Grtz

Hi,

this is an interesting post and quite timely because i am currently reading Patterns of Enterprise Application Architecture (PEAA) by Martin Fowler.

The first chapter is about Layering so here's my take from it:

There is no one layering technique that works in all cases. I believe alot of difference stated in this post about where business logic goes is the choice between 2 particular patterns.

Transaction Script: This is where your service layer also handles your business logic with domain objects being quite simple (if you have them at all). The service methods implement use-cases in an almost one-to-one manner.

Domain model: This is where the service layer is very simple and acts more as a convienient API for the app and a place to demarcate transactions and enforce security. The business logic is all done pure oo-style in the domain objects.

The book says use either depending on your environment. The Transaction Script works well but will cause issues with more complex domains and you have to be disciplined about factoring out duplication. With simpler domains its easier to implement.

The domain model can be alot of work though. It also requires good OO knowledge, something Martin Fowler states "a significant minority of developers seem to be unable to make the shift (to pure OO thinking)". The mapping between rich domain models and the datasource can also become more complex.

I'm no expert by any means but thought that might be useful. I'm still grappling with where to put logic myself. Will keep monitoring this post!

Rakesh

I agree good OO is just hard work ... and you get easily temptated to write 'procedural' style code mostly because you are in an extreme deadline!

But we all know that good OO design comes from experience and in many projects I worked ofn the lead architects or project managers just hired junior developers to do code-monkey work. Not involving them in the "think thank" process will cause that they have to learn OO development by trial and error.

But we all know that most of the time speed of developments is required before quality ...

But that's off topic ;)

No responding on your post ... for me terms like transaction script are new to me, so even the great guru's like to use UBIQUITOUS LANGUAGE :)

I think indeed it would ge nice to divide such discussion into small and medium / large projects. Onze size doesn't fit all but perhaps one particular size would fit small projects and another size would fit the other medium and large projects.

Perhaps we should start a new site dedicated to Spring architectural design (not impl details, not the 'i have an error') where use case problems are in detail explained, architectural designs are suggested for a certain problem and were we can have discussion. Other developers with problems can then read about real life solutions that worked or failed .... well this is ofcoarse utopia ... but a boy can dream can't he ;)

Quote:

---

Originally Posted by rebornspirit

- Most of the time data that should be showed on the view can be represented by the domain object. But there are cases in which we like to show a list of domain objects on the view ... BUT some domain object fields should be replaced by another value under certain conditions ... we cannot simply modify the particular domain object field that needs to be shown because with the next Hibernate flush Hibernate thinks the domain object has changed and it will be persisted. So for those cases we still need dto's.

---

Dunno if I understood you well, but maybe you need some better web framework. There are frequent situations when I have to present list of domain objects on my web page, and for eg. localize value of it's particular field. In Tapestry, during iteration, current domain object is injected back into page (java code), and you can perform any kind of logic on that particular object or field and render HTML results on the page. All logic is placed inside page java class. No need for page-specific DTO. This way you are not forced to prepare everything upfront befor rendering, since render flow goes back to page during iteration.
It was one of best features I encountered when I switched to Tapestry.

Quote:

---

Originally Posted by rebornspirit

- When you start putting logic into your anemic model... suddely your view can access that logic and who nows what happens then ;)

---

Maybe it isn't so bad tradeoff if people who fully understand the architecture also develop UI layer, thus trhey know that touching some logic on domain object is dangerous.

Cheers,
Vjeran

Quote:

---

Maybe it isn't so bad tradeoff if people who fully understand the architecture also develop UI layer, thus trhey know that touching some logic on domain object is dangerous.

---

Yes and no

Yes, if you work on a small non enterprise project.
No, if you work on enterprise projects with complex integration, many developers, long lifespan, multiple new developers over time. I would not like too see the end result of that. Given people access to business logic on the view is tricky, and should be monitored closely, especially risky when that logic can cause multiple database requests. Projects mostly don't have the time for zuch dedicated code reviews, so I prefer to use a view were no business logic can be implemented