The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

balia (5) [Avatar] Offline
#1
I am working on the Flight scheduling, I am using multi-tier architecture,(presentation, facade, services, Domain, Dao) using spring, hibernate, web services frameworks.

So far I have identified the domain model, and am working through the use case realisation
( sequence diagrams, and collaboration diagrams).
The problem I am facing in this complex project, is the distribution of the functionality throughout different layer, in terms of business logic, validation, exception handling.

The way I see it, please correct me if I am wrong. The presentation tier would call the facade, which would call the service layer, which would use the domain objects (create, update, delete) by using the dao, to retrieve or persist the domain objects.

Now would I put the business logic in the domain layer, by creating classes which would manipulate the domain objects in this layer, or include the business logic in the domain objects themselves.
The issue I have in this case, is when the schema changes, I automatically regenerate the domain objects using the tool provided with myeclipse.

Also in terms of creating the tests, to test the model objects, and the functionality, at what stage should the tests be realistically written for projects of this size. I am using agile development method, whereby I took what I thought the be core objects of the domain model.
( Flight, OperatingPeriods, Routing ) in the first iteration, but I find, that I am spending too much time, in the first iteration.

Also, what is the difference between the domain objects, and object model.

Thanks.
ceracm (113) [Avatar] Offline
#2
Re: Multi tier design recommendations
There are two ways of organizing the business logic:
* Domain Model pattern - put the business logic in the domain model objects (entities and value objects)
* Transaction Script pattern - put the business logic in the service layer (which is presumably what you are referring to by "creating classes which would manipulate the domain objects")

I'm not a big fan of code generation tools because of what to do with user-written code if the tool isn't smart enough to not overwrite it. I've seen some projects that put their code in a layer of classes that extend the generated classes. Alternatively, I suppose you could have domain objects that delegate to the generated ones. EIther way its a bit messy when compared to a handcrafted domain model.

I would test early and often. In the first iteration I would focus on an important use case or story rather than focus on the domain objects. I.e. implement a slice of useful functionality rather than focussing on getting the objects just right. With each iteration you add more functionality to the domain objects based on use cases/stories and refactor the domain model to keep it clean.

The terms 'domain objects' and 'object model' can be used interchangeably.

I hope this helps.

Chris
balia (5) [Avatar] Offline
#3
Re: Multi tier design recommendations
Thanks Chris, it was of great help.
Do you tackle the user scenario going from end to end (presentation to Dao), or do you focus on particular layer first.

Thanks.
ceracm (113) [Avatar] Offline
#4
Re: Multi tier design recommendations
Working from the outside in can often be the most helpful - i.e. from the presentation tier down. Alternatively, once you have determined the requests that the presentation tier will make to the business tier you can start working on the business tier. Either way, I think its important for development to be driven by use cases or stories.

Chris
balia (5) [Avatar] Offline
#5
Re: Multi tier design recommendations
Thanks for advice
ManningForumUser (3) [Avatar] Offline
#6
Re: Multi tier design recommendations
Is it possible to split the business logic in the domain objects as well as session beans ?
Business logic that will change can go into the session beans whereas the ones that wont change will go into the POJOS.
ceracm (113) [Avatar] Offline
#7
Re: Multi tier design recommendations
What do you mean by "Business logic that will change"?

I would try very hard to keep the session beans thin and use design patterns such as Strategy and Template method to handle change.

Chris
ManningForumUser (3) [Avatar] Offline
#8
Re: Multi tier design recommendations
> What do you mean by "Business logic that will
> change"?
>
> I would try very hard to keep the session beans thin
> and use design patterns such as Strategy and Template
> method to handle change.
>
> Chris

Well all business logic is subject to change smilie . I come from a completely Transaction Script background. I have to get used to the idea of using domain logic in POJOs. Your book has certainly opened new possibilities.
Would there ever be a situation where I would need session beans if I use POJOs/Spring ?
ceracm (113) [Avatar] Offline
#9
Re: Multi tier design recommendations
A couple of reasons to use session beans:
1. You need to support remote clients that begin a transaction, remotely call multiple services that participate in the transaction initiated by the client.

2. You need to use some app server specific feature that is only accessible through EJBs - not sure what though.

Chris