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:


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 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: , ,

miercuri, februarie 15, 2006

Effective Java

A trecut destul de mult timp de la ultimul post pe blog in timpul acesta m-au vizitat aproape 150 de persoane dupa cum se poate vedea aici. Vizitatorii sunt cu precadere din Europa si State dar si din alte tari ale lumii: cred ca printre ele si Indonezia si China.

Zilele trecute am vizionat in fuga un interviu cu Josh Bloch si Neil Gafter realizat la JavaPolis 2005 de Ted Neward (trebuie sa va faceti un cont pe acest site pentru vizionare). Undeva se vorbea despre o noua versiune a cartii Effective Java. Din curiozitate am rasfoit-o din nou dupa mult timp. E o carte in care se prezinta succint aspecte ale limbajului care ar putea creste calitatea programelor scrise in Java, asa cum marturiseste autorul, mai mult din punct de vedere al claritatii si nu a performantelor (dupa cum stiti optimizarea se face la urma sau deloc).

Josh Bloch a lucrat de la inceputuri ca inginer la Sun chiar in realizarea API-urilor limbajului si este unul din putinii care ar fi putut scrie aceasta carte. In prezent impreuna cu Neil Gafter lucreaza pentru Google si au marurisit ca aceasta firma este foarte interesata de Java. Am auzit de unii romani care lucreaza pentru Google dar nu e acelasi fenomen cum e in cazul Microsoft. Ce e foarte interesant e ca Bill Gates a afirmat ca rivalul Microsoft este IBM si nu Google.

In Effective Java sunt principii de bun simt, pe care din graba sau dezinteres tindem sa le neglijam sau ignoram crezind ca codul nostru nu o sa mai fie niciodata citit. O mare eroare, pentru ca e sigur ca vom scrie codul o data dar de citit il vom citi noi sau altii de mai multe ori.