miercuri, septembrie 14, 2005

Domain Driven Design - Tackling Complexity in the Heart of Software

In sfarsit o carte cu adevarat palpitanta: Domain Driven Design - Tackling Complexity in the Heart of Software.

Este asa, pentu ca trebuie sa rezolv o mare problema care ma preocupa. Refuzul interior de a lua contact cu business-ul abordat. Pentru mine au devenit foarte importante tehnologiile, in special framewor-urile. Dar ele nu reprezinta nici pe departe ceea ce trebuie facut in aplicatii ci mai mult cum trebuie facut. Ele sunt mai mult unelte care te ajuta sa implementezi un business. Dar nu ele dau valoare intrinseca apliactiei.

Dezvoltarea domeniului aplicatiei e ceva ce neglijez de mult. Parca ceva in mine refuza sa ia contact cu business-ul de orice natura ar fi el. Pentru ca e complicat, si nu are o valoare continua. E util numai pentru aplicatia curenta. E complex, e extrem de complex.

E foarte interesant raportul tau cu business-ul modelat. Intr-un fel trebuie sa il cunosti foarte bine pentru ca altfel te blochezi in implementare dar nici nu trebuie sa iti murdaresti prea tare mintea cu el. Deci trebuie sa iei din el o esenta care sa te lege de el. In principiu trebuie sa-I creezi un model, care este o abstractizare a domeniului respectiv care surprinde numai aspectele importante, oricare ar fi ele. Si pe care trebuie sa il stapanesti. Nu te poti lega de business prin amanunte, care se schimba cel mai des. Trebuie sa te legi printr-un model care reprezinta o parte tare.

Cateva citate:

“A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.”

“Domain modeling is not a matter of making as "realistic" a model as possible. Even in a domain of tangible real-world things, our model is an artificial creation. Nor is it just the construction of a software mechanism that gives the necessary results. It is more like moviemaking, loosely representing reality to a particular purpose.

Even a documentary film does not show unedited real life. Just as a moviemaker selects aspects of experience and presents them in an idiosyncratic way to tell a story or make a point, a domain modeler chooses a particular model for its utility.”

“Instead, the technical talent goes to work on elaborate frame-works, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.”


“There are systematic ways of thinking that developers can employ to search for nsight and produce effective models. There are design techniques that can bring order to a sprawling software application. Cultivation of these skills makes a eveloper much more valuable, even in an initially unfamiliar domain.”