User talk:Colaru

Domain Driven Design and enterprise applications Posted on Friday December 23, 2005  http://olaru.blogspot.com I was very confused after read mister Eric Evans book Domain Driven Design. Is a big contrast into the day to day style I work and what he say in his book about rich object domain. Wy they blame the transaction script approach? But now I think this:

This post ideas

- enterprise applications are just a data transport centric model for transporting data from presentation to data source and vice versa

- the business domain notions are reflected in database, business and also in presentation and we must try to reuse as much is possible objects and name conventions ( not over configuration yet) (in my case I reuse VO?s and methods names)

The refined architecture

The architecture is about the integration of the parts in the whole. And is about decisions in this sense. The best refined enterprise architecture that is in now in my mind is this (is a decoupled, layered enterprise architecture; I ignore the modularization, exception handling, security and other specific aspects). It consist in:

A package of value objects VO's aka DTO's that maps to the tables in database (with references from one to others a in the same way to the database constraints). This references will be used for populating ~ persisting a graph of objects instead a single object when is the case. VO?s are Java Beans with properties and setters getters and no behavior. The name DTO is not the best because this objects transports data but represents also a domain perspective.

A package of DAO objects who populate this VO's with data from database, or persist them to database. DAO objects are formed from CRUD operations very granular and orientated to database accessing (no state). The iBatis, Hibernate or a JDO implementation framework can be used for automating and abstracting this process of populating ~ persisting VO?s.

A service package who represents the presentation accessing perspective. Is a layer of objects with service methods used from the presentation Actions. This objects contains the calculations operations and use a series of services (no state), offered from application server, auxiliary libraries, etc. This objects externalize to DAO package the persisting ~ populating VO?s, and try to reuse DAO methods and to offer transactions support for this operations. The Spring framework can be used for dependency injection (wiring), AOP services weaving, declarative services, etc.

A package of actions objects who use a package of actions forms populated with page parameters. The actions are used from front servlet for delegating the user actions and the form objects are used for accessing user parameters. This action forms beans reuse VO's when is the case. You can use Struts or other request-response or component oriented Web framework for automation your forms populating. The actions control de interface flow and use the service package objects.

A package of view objects who encapsulate and reuse VO's and eventually contains other data for the JSP page perspective. They are populated from services and send to view (JSP?s) for presentation, in a MVC style. The JSP (or other view technology like Velocity) know just their structure not their values. They are page oriented, in the sense that they contain all the data that a page need to display.

The domain for me is formed from two classes of objects: the services who are a sort of entity objects and VO?s the value objects. VO?s are used for transporting data into the applications packages and into layers. Services are just a way to accessing data from the presentation perspective using value objects (generally are singletons).

The first modeling is the database and here I expect to identify the domain language (the words who express the domain). Then the VO?s who maps to the database tables will represent this words. But the perspective is meet in the middle style in sense that one end of the application is the interface, and the other end is the database. And the junction point is in the middle between the service package and DAO package. Services reflects the view and DAO reflects the database. DAO?s are coarse grained and services uses them in a ne to many relation.

General observations

All this flux can be managed with a stack of 3 technical frameworks like this: a Web framework, a light container, a ORM framework. And you can use other frameworks for different other things: Axis for WS, Lucene for searching, iText for PDF generating, etc. The EJB?s seam?s to be the old monolithic solution for this. The Spring framework seam?s to be a liant, and a important piece in this game. Is a framework who unify this vision.

The presentation layer is represented from: JSP?s, actions, action forms, a (front) contoller. A MVC framework can be used for a good approach.

The domain layer is represented by: session package, VO?s package, view package. A light container can be used for a good approach.

The data source layer is represented by: DAO package, queries, data saurce. A ORM framework can be used for a good approach.

The need for automation

In this game there are three mammoths implied: the browser, the application server and the database server. And some protocols for communication who has nothing in common with the object world (in this case just the application server knows to work with objects).

The HTTP protocol is a non object oriented protocol (a text transporter) used for transferring information?s from Web browser to application server. The SQL standard is used as support for transferring data from application server to database server and vice versa.

And the orientation is for automating the VO?s populating:

- Action Forms (who can reuse VO?s) population can be automated using a Web framework like Struts

- Value Objects can be populated in a automatic way with a ORM framework (there are some oriented query language like HQL or JDOQL)

And other interesting observations:

- the declarative way of do programming

- the try to keep the synchronization throw database and domain objects.

Some observation about reuse

An good convention example are the simpler JavaBeans. In this case the setters and getters are a example of convention; the bean processor/user will know that a bean will have this setters an getters and will use them

An example of convention unused is that the action name is the same with the service name many times. And the database fields are identical with the VO?s fields. I think that we can speculate this things for a little number of code lines in our aplications.

Other types of reuse are this:

- the DAO methods are reused from different services

- the queries can be formed from reusable sequences (iBatis support or Velocity)

Conclusion: we must clarify some things For our happiness we must clarify some things:

1) The enterprise applications are doing just data transporting from interface to database and vice versa in a distributed way? They represent a a game between this ends: the presentation and the data source with some calculation and services in the middle? Because your application is distributed you must control the objects proliferation? For distribution style you are constrain by the JVM threads to use a procedural style? In what way you will manage your persistent data. What are the ways to offer services to your application? 2) What is the role of modern frameworks in our applications (they come with architecture for our applications as a part of inversion of control style). And if you use a framework (like a Web framework ~ Struts, JSF, a light container like Spring or Hivemind, or a ORM framework ~ Hibernate, iBatis) you adhere to an architecture. What is the influence in your modeling?

Cristian Olaru http://olaru.blogspot.com