««« | »»»

OR Mappers: pro e contro i domain models

Una obie­zione che viene subito in mente con­tro l’idea di ridurre i domain objects a sem­plici EOGenericRecord è quello dell’antipattern (o code smell, fate voi) del cosi­detto Anemic Domain Model:

The basic symp­tom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are con­nec­ted with the rich rela­tion­ships and struc­ture that true domain models have.

The catch comes when you look at the beha­vior, and you rea­lize that there is hardly any beha­vior on these objects, making them lit­tle more than bags of get­ters and set­ters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of ser­vice objects which cap­ture all the domain logic. These ser­vi­ces live on top of the domain model and use the domain model for data.

Sembra una descri­zione esatta di quello a cui porta il mio approc­cio. Ci sono però delle ulte­riori con­si­de­ra­zioni da fare.

Prima di tutto, l’EOGenericRecord non è pro­prio una sem­plice Data Class e for­ni­sce già un bel po’ di logica pronta all’uso e se non basta c’è la ver­sione pom­pata di Wonder. Di con­se­guenza il mio approc­cio sem­bra più a quello che viene defi­nito un Service Layer:

Application Layer [his name for Service Layer]: Defines the jobs the soft­ware is sup­po­sed to do and directs the expres­sive domain objects to work out pro­blems. The tasks this layer is respon­si­ble for are mea­ning­ful to the busi­ness or neces­sary for inte­rac­tion with the appli­ca­tion layers of other systems. This layer is kept thin. It does not con­tain busi­ness rules or kno­w­ledge, but only coor­di­na­tes tasks and dele­ga­tes work to col­la­bo­ra­tions of domain objects in the next layer down. It does not have state reflec­ting the busi­ness situa­tion, but it can have state that reflects the pro­gress of a task for the user or the program.

Domain Layer (or Model Layer): Responsible for repre­sen­ting con­cepts of the busi­ness, infor­ma­tion about the busi­ness situa­tion, and busi­ness rules. State that reflects the busi­ness situa­tion is con­trol­led and used here, even though the tech­ni­cal details of sto­ring it are dele­ga­ted to the infra­struc­ture. This layer is the heart of busi­ness software.

In secondo luogo non mi sem­bra che le argo­men­ta­zioni di Fowler siano molto con­vin­centi. È vero che l’accoppiamento fra dati e pro­ce­dure è la ragion d’essere dell’OOP ma que­sto non dimo­stra che sia sem­pre l’approccio migliore (cosa che anche Fowler rico­no­sce). Inoltre non viene por­tato un sin­golo esem­pio con­creto di una situa­zione in cui un Domani Model è chia­ra­mente supe­riore, a parte gli esempi ovvi.

Distinguere chia­ra­mente i pro e i con­tro è dif­fi­cile anche per­ché i cri­teri di valu­ta­zione sono in parte teo­rici e in parte pra­tici (almeno nel mio caso). Ci torneremo.

Per proseguire

Commenti e trackback sono disabilitati.

• Tweets, 2012-05-20
• Tweets, 2012-05-13
• Tweets, 2012-05-06
• Tweets, 2012-04-29
• Tweets, 2012-04-22