Book: "Domain driven design" implemented in Spring

[apostiglioni]

Originally Posted by vmarcinko

And if "fire" logic is put inside Employee domain object, then 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?

This is for me a good point for dtos. I have just posted a reply where I describe an architecture I worked with, using dto's with great success. This types of things makes me question whether is it true that DTO's are an anti-pattern. Why is it better to couple the presentation layer to the business model and expose methods that should not be exposed rather than use DTOs?

[Colin Yates]

If you are implementing to interfaces anyway then it shouldn't really matter....the interface that the view uses doesn't expose the "fire" method. Of course, if you know that there is a single object implementing all the different interfaces then you can still cast them (i.e. ReadOnlyEmployee, FireableEmployee...silly names, but you get the idea), but you would explicitly need to do that.

Just a thought in passing.

[apostiglioni]

Originally Posted by rebornspirit

The MyService interface implementation looks something like

public class MyServiceImpl implements MyService {
 
    private ViewObjectAssembler assembler;

    public ViewObject getSomething(Integer id) {
        MyDomainObject do = ... retrieve the domain object;
        return assembler.assemble(do);
    }
}

and a custom assembler being set by Spring:

Two comments about this:
1. what if the same service has to be used in the same application context but for different views?
Suppose an ABM where different data from the same object can be accessed by different users? How do you handle this with spring without support for runtime mappings?
2. It smells like the last line of code would be the same for ALL the services. Perhaps a better approach is to put a proxy (dynamic perhaps) on top of the service layer where this logic would be written only once. And as an additional benefit, my service layer doesn't have to know anything about how the data it returns would be used.

[hucmuc]

Originally Posted by apostiglioni

This is for me a good point for dtos. I have just posted a reply where I describe an architecture I worked with, using dto's with great success. This types of things makes me question whether is it true that DTO's are an anti-pattern. Why is it better to couple the presentation layer to the business model and expose methods that should not be exposed rather than use DTOs?

After using the domain model (contains business logic) and the DTO patterns (only setters and getters), I have to say the domain model can never be really used in a consistent way in a multi-tiered system.

[Chuck Zheng]

After reading the thread with great interest. I see many different opinions and still not sure about how to impl domain model with spring. I have following questions:

1. should domain object modelled as spring bean?

2. if yes - who manage domain object relationships, spring or hibernate? think of example: an order has many line items, each line item refer to product

3. if not - and everyone is agreeing that domain object should contain biz logic. what if order object wants to find any product on its lineitems has unit price greater than $1000 (this product may need company authorization before ordering). how should order run this query on product? - I assume DAO are spring bean.

4. also if biz logic in domain object. what should service layer do? is service a spring bean?

cheers
chuck

[amin]

Hi

Basically the general architecture should look something like this

Client ----> Business Delegate ---> Service Layer (Implements business use case) ----> Business Objects (otherwise known as Domain Objects) ---> DAO ---> DBMS.

Thanks
Amin

[Chuck Zheng]

What is your BusinessObject?
- Are they like Order, Invoice, Item?
- Are they managed by spring?
- who is managing relationships among Order and Item? spring's dependency injection or ORM - like hibernate? - if you use spring, I am very interested in knowing how do you manage it with a 400+ Biz Object system

I would have ORM to manage object relationships, not spring. spring manages the (MDD-sytle) Repository for Biz Object and naturally works well with DAOs.

I'm not sure Biz Service is for Use cases, according to MDD, Service is some essentail concept identified in the domain model. and it should be reusable across many use cases. I would have Service on the same level as Repository and have UseCase layer on top of them.

What do you think?

cheers
chuck

[Colin Yates]

are they managed by Spring?

Is an interesting question

Have you checked out @Configurable? http://static.springframework.org/sp...atconfigurable

This means that they can be wired up by Spring even if Spring isn't responsible for creating them!

You do need to use the aspectj runtime but....

[benethridge]

See new thread:

http://forum.springframework.org/showthread.php?t=29694

...since I quoted people in this thread on that new one.

Ben

[nadhimoolam]

I hope, things have improved a lot on Validation @ Service layer. Could anyone throw some good example of how to validate domain object in Spring service layer?

Thanks,
Nambi