joi, februarie 23, 2006

Domain Driven Design and enterprise applications

Am decis sa public din cand in cand in engleza. Mai ales aspecte tehnice. Un mare ajutor am gasit in autocorect-ul si autosugest-ul din Word. De asemenea dictionarul Babylon. Mai demult foloseam Everest. Intrarile in engleza le voi posta pe JRoller alaturi de ceilalti weblogeri din Java. Voi publica pe blogger doar fragmente.

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. Why they blame the transaction script approach? But now I think this:


- 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 ther specific aspects).


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.


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?

category: , ,