I'm currently reading up on some architectural knowledge and know there isn't "the one solution".

But, there are some generally good designs like a layered architecture etc.

I'm about to give you my current view of what I have learned so far with some additional questions on good practices.

UI Layer

Views of the data and controllers managing the data in the views. Common technologies is HTML, JSP, Swing, AWT etc.

Service Layer

The access point between the views and the business rules. Common technologies is Servlets, EJB or just POJO's.

Application/Business Layer

Contains our business rules and objects. Technologies commonly used is EJB and POJO's.

Domain Layer

Describes the domain. Simple POJO's mapped to *.hbm.xml.

Data Source/Integration Layer

Controlls access to our repository (database, filesystem or whatever).


My questions:

1. Is the objects describing the domain in the Domain Layer my DTO's (Data Transfer Objects) / VO (Value Objects)?

2. What kind of logic could the domain model/objects contain?

3. Is the Service Layer and UI Layer supposed to know about my domain model/objects or should I create some generic view of the domain model/objects and pass it on to these layers?

4. Is the transaction management supposed to be done in the Service Layer or the Business Layer, maybe both?

Thats all for now!

Kind regards, Andrew[/i]

it's only my point of view, i might be wrong in several ideas but if it can help you....
and again, excuse me for my english


many people don't want to use DTO because it can be evil to manage.
I use DTO because :
- my views (jsp) don't need all the graph of objects and the network can suffer of such data overhead between controller and views
- i want to "isolate" business objects which are persistent (domain layer) in my business layer
Your domain model describes all objects, associations, properties, and "entity business methods" you need.
Your views are generaly not exactly structured on your domain model.


it's an object view of your business, for example it can handle "object specific" business (all business you can do with the specific entity).
You need the object view to do your business, you need relationnal db to store the Data, you need ejb or ORM to do your job :)


The service layer uses POJO getting them from a DAO layer, it will use many pojo to give the service. If your app need a view in which you can see the client and order informations, the service will get the corresponding info (it's only an example), it will need both client and order pojo


My access point between the views and the business rules is a controller struts servlet. This layer don't have to know about business, so my transaction are managed in the business layer but not directly, there are some hidden transaction tools...
If you use ejb, or pojo, on of the big difference is here...

[/quote]

1. Um, not AFAIK. DTO:s are used when you want to show some data to the user, but you don't want to expose your domain objects directly. For a typical webapp where everything runs in one VM I think it's often easier to just use the domain objects directly.

2. As much of the logic as possible should be in the domain model. Specifically, it might be good advise to avoid the anemic domain model, see http://www.martinfowler.com/bliki/AnemicDomainModel.html. However, for a simple CRUD app there really isn't much logic to begin with and your domain model will in practice be "anemic", and there's nothing you really can do about that.

3. The service layer is supposed to be the interface which the UI code uses to manipulate the domain model, so I think it's necessary that it knows about the domain model. The UI doesn't necessarily need to know about the domain model; as explained in the first point you can use DTO:s to insulate the UI from the domain model if you want.

4. Service layer I would say, but see below.


I would say that my view of a "best practices" architecture is slightly different than yours. Let me explain:

UI

Basically, same as your explanation. E.g. web UI with struts/jsp, fat client (swing), web services (some xml stuff), batch utilities run via crontab etc.

Service

Interface to the domain model for the UI layer. Typical duties are security checks, transaction management, retrieving and storing domain objects via the DAO layer. Should be stateless.

Data source/integration

Basically static methods or singletons containing logic to retrieve and store domain objects to the database, or to some other system via webservices etc. Should be stateless.

Domain model

The core of the application. As much of the logic as possible should be in the domain classes, with the constraint that the domain classes should only depend on other domain classes (i.e. no calls to the DAO layer or the service layer). Some, or most, of these classes need to be persisted, and thus have hibernate mappings (if using hibernate).

As you see, the biggest difference is that in my explanation, there is no separate app/business layer. Instead I have a "rich" domain model (as opposed to simple POJOs, with basically only properties and their get/set methods, as I understood your domain model to be?). With some lesser ORM tool, like Entity EJB:s, it might be necessary to have some layer under the domain model for the persistent objects. In that case I guess the architecture would then be similar to yours, only the names of the layers would be different.

Another smaller difference is that I wouldn't put servlets in the service layer. Rather, servlets (or struts action classes or whatever you fancy) belong to the UI layer as controllers.

Thanks for your respons guys!

I don't really get it then; what's a domain model?

In J2EE: is the Entity Beans my domain elements?

In a layered architecture without EJB: POJO's?

In hibernate we map objects to *hbm.xml files. Those objects what are they representing in the architecture model?

Seems I'm not getting things right, could anyone give a more concret example mapping technologies (Java) with some of the layers?

Hey, I may be stupid but I'm about to learn! ;-)

/Andrew

An example of an system I've built with "J2EE approach" (I think) without the use of EJB's:

UI Layer

A Swing client with it's controllers. The controllers accessed "Services" through the...

Service Layer

...which acted as an "system facade", exposing the system services to the client. In these "service" classes we got the business objects from the application server via JNDI and a Service Locator. Some transaction management is used here (in cases of direct access to the database through a Fastlane).

Business Layer

Contained the business rules, working with the domain objects (those mapped into *hbm.xml). Business objects (simple POJO's) got references to the DAO's via the Service Locator. Transaction management used heavily in this layer.

Data Source Layer

Contains all of our data access objects. Classes used for managing our access to any repository (database, filesystem etc.)

Domain Layer (model)

Our objects mapped to *hbm.xml files. Simple POJO's. These objects where known by all the layers, which I feel is bad but I lack the knowledge of how to design it better (here's where you guys step in with your views). Though, these objects only knew about each other.

joib,
you're right my definition of service was wrong (bad translation) but my point of view is sensibly the same.
All the difficulty is here :

for the business rules that cannot respect this method, where do you code them?

Replace "depends" with "integrates" and will not see any problems in Layered architecture :)

Well yes, the minute you descend from pure OO-la-la-la-land down to the real world you're going to face these kinds of issues. Basically, you have two choices:

1. Call DAO or service classes from your domain classes.

+ You keep the domain logic in the domain classes

- Domain model becomes dependent on your persistence strategy. Thus it becomes more difficult to test the domain model (you can't test it in isolation any more).

2. Move some logic to the service layer

+ Keeps the domain model independent of the rest of the system.

- Some logic moves to the service layer. Take it too far, and you have the "anemic domain model", i.e. basically C style programming with functions (methods in the stateless service objects) and structs (your domain model, being nothing more than holder of data, without behaviour).

Personally, my opinion is that #2 is the lesser of two evils. Usually, there is no need to go all the way to #2, e.g. you do as little as possible in the service layer so that you can move to the domain layer as quickly as possible. You should always strive that as much logic as possible should be in the domain model.

i totally agree with previous post, we use the second solution too

Most of RPC, messaging, web applications I have ever saw are designed this way ("procedures" and "structs"). It is not a bad way, It is just not OOP way. DB schema is a domain model for this kind of applications (the same as object model if you can map both).

It depends on what MVC model you are using, for this issue you can search for MVC and Struts (very clear implementation of MVC) on Google.

oups struts only covers View + a part of controller, certainly not the model...