> ei se ole mikään fowlerin kontroversiaali idea
> vaan ikiaikainen OO-periaate. domainluokissa
> _pitää_ olla logiikkaa !

Miksi? Mitä sillä saavutetaan ja miten se parantaa koodin ylläpidettävyyttä?

Minulle ei riitä se, että ukko ylijumala Fowler sanoo jossain rapakon takana, että tehkää näin. Se, että joku hämäräveikko kirjoittaa 7000 rivisen service-luokan, ei mielestäni riitä myöskään perusteluksi sille, että sovelluslogiikkaa vietäisiin domain-malliin. Juuri tämän takia ns. service-domain-jaottelusta on nähdäkseni tullut niin suosittu.

Serialisoinnista pitäisikin sitten kirjoittaa oma juttunsa.

tämmönen datan ja logiikan erotteluhan on ihan kamalaa, ei se ole mikään fowlerin kontroversiaali idea vaan ikiaikainen OO-periaate. domainluokissa _pitää_ olla logiikkaa ! muuten kannattaa harkita jotain möhkö-service-haroo-JDBC:tä-tekniikkaa ilman minkäänsorttista mallia.

jos domain-luokka lihoo niin silloin kannattaa miettiä onko se domainmalli tarpeeksi hienojakoinen. jonnekin se bloat joka tapauksessa menee, terv. nimim. “olen nähnyt 7000 rivin service-luokkia”.

samaa mieltä kyllä service-kutsuista domain modelin seassa, ihan liian sekavaa kenen pitäisi kutsua missä ja ketä, onko joku kutsunut jne. yksi tapa on pitää ne poissa domain-luokista ja tehdä kutsut service-tasolla. nyt siis service == “ulkoinen” järjestelmä niinkuin tietokanta tai “documentService”.

serialisoinnista … sitä voisi ensinnäkin välttää kun vain mahdollista ja jos on pakko kuljetella niitä jonnekin niin silloin se on DTO-aika …

Lueskelin lisää aiheesta ja useammalla “rich domain modelia” ajavalla saitilla suositellaan domain-malliin sijoitettavaksi liiketoimintasääntöjä, laskentasääntöjä ja validointeja. Nämähän eivät useasti ole suoraan riippuvaisia palvelukerroksesta:

En ole oikein tästäkään vakuuttunut. Joissain tapauksissa esimerkiksi liiketoiminta- tai validointisäännöt ovat staattisia, eivätkä muutu tilanteen mukaan (esimerkiksi shakkipelissä säännöt ovat aina samat), mutta esimerkiksi liiketoimintajärjestelmissä sääntöjä tulee voida muuttaa, eikä niitä näin ollen voi kovakoodata domain-luokkiin.

Tietysti domainlogiikkaa (kuten Fowler sitä kutsuu) voidaan parametroida varsin vapaasti, mutta siltikin sijoittaisin nämäkin toiminnallisuudet domainin ulkopuolelle.

Kuten asia JBoss Rulesin dokumentaatiossa ilmaistaan:

“- Logic and Data Separation

Your data is in your domain objects, the logic is in the rules. This is fundamentally breaking the OO coupling of data and logic (this can be an advantage as well as a disadvantage depending on your point of view). The upshot is that the logic can be much easier to maintain as there are changes in the future, as the logic is all layed out in rules. ”