DDD Can I drop my service layer

[Alarmnummer]

Ik ben bezig met een setje van blogs of domain driven design. Ik wil oa discussies uitlokken omdat ik zelf eigelijk nog helemaal geen systemen heb gezien met rijke domain modellen. Ik vraag me dus af wat de gevolgen gaan worden voor het systeem en hoe eventuele problemen opgelost kunnen worden. Ik had een post in elkaar gezet maar heb van een aantal mensen gehoord dat ze het tempo erg hoog vonden, en de conclusies erg kort door de bocht (of niet onderbouwd). Dit klopt: ik wil niet dat de post erg lang gaat worden en als ze iets willen weten/het ermee oneens zijn, dan kunnen ze comments geven (verder zijn de meeste dingen al zo vaak besproken dat ik eigelijk weinig behoefte had om het nog een keer te vermelden). Ik zit nog een beetje te twijfelen hoe en of ik dit stuk ga aanpassen. Dit is trouwens wel een stuk voor mensen die al redelijk wat afweten van DDD.

-------------------------------------------------------------------------------
DDD: Can I drop my Service Layer?

Intention:
This if the first of hopefully many thoughts about Domain Driven Design.
In this post I want to explain why the Service Layer remains a usefull
construct when a rich Domain Model is used instead of an Anemic Domain
Model.

I don't think the Service Layer (PEAA), the layer under the
presentation/remoting layer, should be dropped. It is true that the
Service Layer will contain less logic because with an Anemic Domain
Model, most logic is placed in the Service Layer (see Transaction Script
in PEAA). But with a rich Domain Model (where most objects have state
<b>and</b> behaviour) the domain specific logic can be moved to the
Domain Objects (objects in the Domain Layer). So at first sight it
appears that the Service Layer is not of much use anymore, because all
domain logic will be removed from it.

But the Service Layer is still very usefull: it is a gateway to the
internals of your system and this makes it an excelent place to
coordinate (crosscutting) concerns like transactions and security.
This means that layers on top of the Service Layer, should not call
methods that change the state of the Domain Objects directly, but should
call methods in the servicelayer instead. Exposing domain objects in the
layers above some find questionable and Data Transfer Objects (DTO's)
are returned instead. I don't have a problem with both approaches (DTO's
vs Domain Objects) because they both have their pros and cons.

Another advantage of the Service Layer is that it decouples the layers
above the Service Layer, from the Domain Layer (that is below/part-of
the Service Layer), because the Service Layer also acts like a Facade:
it hides the retrieval of, and delegation to domain objects from the
layers above. You don't want this responsibility in those layers,
because it tightens the coupling. I think that decoupling will prove
itself even more valueable with rich Domain Objects because they are
likely to be refactored more often. You want to prevent that every
change in the Domain Model will lead to a change in the other layers.

And last but certainly not least is that the Service Layer is a good
place to place Application Logic. Application logic is logic that is not
part of the domain, for example returning an Excel sheet containing all
employees. The concept Excel sheet doesn't have any meaning in the
employee-domain and therefor it doesn't belong in the Domain Model.

So the Service Layer still remains a very important layer and I expect
that the interface stays the same if you use a Anemic Domain Model with
Transaction Scripts or a rich Domain Model. But what is it going to look
like if you use a rich Domain Model? If I ignore crosscutting concerns
like transactions and security (these can be added declarative) and
application logic, the Service Layer retrieves the the Domain Objects
that are going to do the work and delegates the task to them [te strakke
conclusie]

code:

class EmployeeManager{
       private EmployeeDao employeeDao;

       public void fire(long employeeId){
               Employee employee = employeeDao.load(employeeId);
               employee.fire();
       }
}

[ Voor 5% gewijzigd door Alarmnummer op 29-05-2006 14:15 ]

[Verwijderd]

Als ik het goed begrepen heb wil je dus een discussie over het nut van de service-layer in de context van DDD? Volgens mij bijten die elkaar niet; zoals je zelf al aangeeft herbergt de service layer meer de "process logic" (security, transaction management, logging), die weinig met de business objects (business logic) zelf te maken heeft (en dus bij een rich model ook niet op de domein objecten zelf wordt geplaatst). Bij mij vind je in die laag over het algemeen Service Facades of Use-Case Controllers.

Je conclusie is inderdaad een beetje nauw, maar geeft wel de essentie van de service layer aan denk ik (in ieder geval zoals ik deze interpreteer): een consistente single point of entry voor je systeem creëren, die de use cases implementeert door taken naar de relevante business-objecten te delegeren.

Bij mij zou je employee fire er overigens (ongeveer) als volgt uitzien (weinig verschil):

C#:

public class EmployeeFacade
{
  [security-attributes]
  [logging-attributes]
  public void FireEmployee(DomainId employeeId)
  {
    Employee employee = EmployeeRepository.FindById(employeeId); // delegeer naar O/R Mapper
    employee.Fire();
    Request.UnitOfWork.Commit(); // en wederom
  }
}

[ Voor 6% gewijzigd door Verwijderd op 29-05-2006 20:02 ]

[EfBe]

Volgens mij is dit een discussie die volledig voorbij gaat aan het feit wat het practisch nut is van al deze moeite. Een zeker design wordt gekozen omdat het het best past bij wat geeist wordt, het minste nadeel oplevert bij implementatie, het beste verwoordt wat de klant wil etc.

Of een service layer er nu wel of niet moet komen is IMHO een discussie die helemaal niet interessant is. Immers, je onderwerp is een oplossing voor een probleem. De motivatie voor de KEUZE voor die oplossing geeft dus antwoord op de vraag of de gekozen oplossing de juiste is voor het probleem. Jouw posting gaat IMHO voorbij aan zowel het initiele probleem (!) en de motivatie voor de keuze.

Immers, beide zaken geven al reden genoeg of je wel danwel niet voor een service layer, DDD, TDD, Agile en weet ik wat voor termen er nog meer gepredikt worden door boekenschrijvers-en-broodsprekers, te kiezen. Het beargumenteren waarom je wel voor zo'n layer moet kiezen is dus IMHO volledig zinloos zonder een probleemstelling EN argumentatie voor de keuze voor een zekere oplossing binnen de context van de probleemstelling.

[Verwijderd]

EfBe schreef op maandag 29 mei 2006 @ 19:16:
Volgens mij is dit een discussie die volledig voorbij gaat aan het feit wat het practisch nut is van al deze moeite. Een zeker design wordt gekozen omdat het het best past bij wat geeist wordt, het minste nadeel oplevert bij implementatie, het beste verwoordt wat de klant wil etc.

[..]

In tegenstelling tot het vele overdesign in de OO-wereld vind ik de service layer eigenlijk een hele logische en nuttige laag in een applicatie (bovengegeven definitie in acht nemend). Praktisch elke applicatie wordt gebaseerd op bijv. use-cases en geconfronteerd met het vraagstuk waar de business-object overstijgende logica te plaatsen; daar biedt dit 'pattern' een eenvoudige oplossing voor, welke zeker niet veel moeite kost om te implementeren.

offtopic:
Ik had overigens bijna een mooie, pragmatische opmerking van je ge-quote in mijn bovenste post om je voor te zijn (maar kon 'm niet meer terugvinden)

[Alarmnummer]

Verwijderd schreef op maandag 29 mei 2006 @ 18:18:
Als ik het goed begrepen heb wil je dus een discussie over het nut van de service-layer in de context van DDD? Volgens mij bijten die elkaar niet

Idd. Maar ik heb andere geluiden gehoord (dus het droppen van de service layer). Dus wat voor mij vanzelf sprekend lijkt, is voor anderen schijnbaar niet zo vanzelfsprekend. Dus vandaar dat ik er toch iets over kwijt wou om duidelijk te maken dat de service layer nog steeds een belangrijke laag is.

Je conclusie is inderdaad een beetje nauw, maar geeft wel de essentie van de service layer aan denk ik (in ieder geval zoals ik deze interpreteer): een consistente single point of entry voor je systeem creëren, die de use cases implementeert door taken naar de relevante business-objecten te delegeren.

Pcies.

Bij mij zou je employee fire er overigens (ongeveer) als volgt uitzien (weinig verschil):

C#:

public class EmployeeFacade
{
  [security-attributes]
  [logging-attributes]
  public void FireEmployee(DomainId employeeId)
  {
    Employee employee = EmployeeRepository.FindById(employeeId); // delegeer naar O/R Mapper
    employee.Fire();
    Request.UnitOfWork.Commit(); // en wederom
  }
}

Dat lijkt er idd heel erg op. De Unit of Work is in mijn geval niet noodzakelijk want die zit aan een threadlocal gebonden en load call die zet hem meteen in de sessie neer (als OR mapper gebruik ik Hibernate meestal). Dus alle updates hoef je niet eens aan een dao door te geven (alleen inserts en deletes). En verder geef ik de voorkeur (een persoonlijke smaak) om de metadata (attributes/annotations) in de Spring configuratie neer te zetten. Dan heb je alle meuk bij elkaar staan. Verder leg je de verantwoordelijkheid ook niet bij de service neer + je maakt je service minder afhankelijk van je 'container'. In .NET is dit allemaal minder belangrijk maar in Java meer ivm de keuzemogelijkheden.

Maar ik ben nog aan het broeden over dao problematiek en entities. Ik hoor geluiden dat mensen helemaal geen dao`s in hun domain laag willen, persoonlijk heb ik er helemaal geen probleem mee.

[ Voor 3% gewijzigd door Alarmnummer op 30-05-2006 10:34 ]

[Alarmnummer]

EfBe schreef op maandag 29 mei 2006 @ 19:16:
Volgens mij is dit een discussie die volledig voorbij gaat aan het feit wat het practisch nut is van al deze moeite. Een zeker design wordt gekozen omdat het het best past bij wat geeist wordt, het minste nadeel oplevert bij implementatie, het beste verwoordt wat de klant wil etc.

Uiteraard. Maar de meeste systemen worden opgezet met standaard constructies en technieken (die goed uitgedacht zijn en veel mensen ervaring mee hebben). Hierdoor kun je er eenvoudiger over redeneren ipv dat ieder systeem weer een volledig nieuwe aanpak heeft.

Verder kun je met standaard 'grote lijnen' ook meer focussen op de inhoudelijke problematiek: domain/applicatie inhoudelijke problematiek.

Immers, beide zaken geven al reden genoeg of je wel danwel niet voor een service layer, DDD, TDD, Agile en weet ik wat voor termen er nog meer gepredikt worden door boekenschrijvers-en-broodsprekers, te kiezen. Het beargumenteren waarom je wel voor zo'n layer moet kiezen is dus IMHO volledig zinloos zonder een probleemstelling EN argumentatie voor de keuze voor een zekere oplossing binnen de context van de probleemstelling.

Dit zijn echt volledige standaard structuren die je in veel systemen (zeker als je in de Spring hoek zit) terug zult vinden. Dus vandaar dat je er in algemene lijnen over kunt redeneren zonder naar specifieke software eisen te kijken. Ik bouw zo nu en dan ook systemen waar helemaal geen service layer in zit, maar in ver weg de meeste systemen is het terug te vinden.

Ik snap dus niet helemaal waar je heen wilt met je opmerking.

[ Voor 14% gewijzigd door Alarmnummer op 30-05-2006 09:14 ]

[EfBe]

Alarmnummer schreef op dinsdag 30 mei 2006 @ 09:09:

Ik snap dus niet helemaal waar je heen wilt met je opmerking.

Je posting komt over alsof het gaat over 'design om het design'. Men moet niet problemen zoeken die er niet zijn.

[Alarmnummer]

EfBe schreef op dinsdag 30 mei 2006 @ 09:26:
[...]

Je posting komt over alsof het gaat over 'design om het design'. Men moet niet problemen zoeken die er niet zijn.

Ok. Dat was niet de bedoeling. Maar de service layer is wel een vrij 'standaard' laag in systemen, dus vandaar dat ik dacht dat iedereen wel begreep dat het niet gaat om design om design. Maar gewoon een algemeen probleem: hoe gaat de service layer beinvloed worden door domain driven design.

[edit]
In de Spring wereld gaat DDD binnenkort een belangrijk onderwerp van gesprek worden. Sinds Spring 2 is het mogelijk om dependencies in domain objecten te injecteren, dus een rijk domain model is dan ook veel eenvoudiger.

[ Voor 21% gewijzigd door Alarmnummer op 30-05-2006 09:40 ]

[Alarmnummer]

Geplaatst:

http://peter.jteam.nl/?p=17

[EfBe]

Dat is wel een erm... groot font in de title van die blog

[Alarmnummer]

EfBe schreef op woensdag 31 mei 2006 @ 19:07:
Dat is wel een erm... groot font in de title van die blog

Moet natuurlijk wel opvallen he

[The - DDD]

Face it, ppl.

Ik own gewoon.

[Alarmnummer]

Mijn font is groter dan die van jou

[The - DDD]

Damn!

En weer terug on-topic.

[ Voor 75% gewijzigd door The - DDD op 31-05-2006 19:39 ]

[Michali]

Als ik DDD goed gelezen heb, dan staat daar toch niet in dat er geen services nodig zijn? Wat ik ervan begrepen heb is dat services juist een onderdeel van het domein zijn en geen laag eroverheen. Soms werk je met domein objecten direct, en soms puur via de services. Althans, dat is hoe ik nu wel werk.

[Verwijderd]

Michali schreef op vrijdag 02 juni 2006 @ 08:08:
Als ik DDD goed gelezen heb, dan staat daar toch niet in dat er geen services nodig zijn? Wat ik ervan begrepen heb is dat services juist een onderdeel van het domein zijn en geen laag eroverheen. Soms werk je met domein objecten direct, en soms puur via de services. Althans, dat is hoe ik nu wel werk.

De services die jij bedoelt hebben betrekking op belangrijke processen danwel transformaties in de domeinlaag, waar geen van de geïdentificeerde domain- en value-objecten verantwoordelijkheid voor draagt. De service layer is een heel ander concept (zie ook PoEAA):

Het doel van de service layer is een consistente single point of entry voor je systeem creëren, die de use cases implementeert door taken naar de relevante business-objecten te delegeren

[ Voor 7% gewijzigd door Verwijderd op 02-06-2006 10:30 ]

[Alarmnummer]

Michali schreef op vrijdag 02 juni 2006 @ 08:08:
Als ik DDD goed gelezen heb, dan staat daar toch niet in dat er geen services nodig zijn?

Het is erg belangrijk om te realiseren dat servicelayer bij fowler iets anders zijn dan services in ddd.

In DDD heb je services op verschillende nivo`s:
-application services (drukken uit wat je applicatie kan doen -> dat komt overeen met de service layer van fowler).
-domain services (als domain logica te complex of onlogisch is om bij een entity/value object onder te brengen zou je een zelfstandig object kunnen introduceren die deze logica in zicht heeft, een voorbeeld van ee domain service zou een overboekingservice kunnen zijn die geld van rekening 1 naar rekening 2 overboekt. De logica hiervan is wellicht zo complex dat je dat niet bij de rekeningen wilt onderbrengen. Een andere reden om een zelfstandig object te introduceren is als je de logica niet echt bij een domainobject kunt onderbrengen.
-infrastructuur services zoals versturen van email bv.

Ik bedoel met mijn 'servicelayer' de functies van ddd zijn applicatie laag. Ik heb het dus over martin fowler zijn 'services'.

En ik vond het zelf ook erg voor de hand liggend dat de service layer nog steeds een erg handige layer is. Maar ik heb een aantal mensen gesproken en sommigen vonden het net zo vanzelf sprekend als ik, en anderen die vonden het totaal niet vanzelf sprekend: ze willen bv direct de domain layer aanspreken en dat is imho niet goed. Dat is de reden dat ik de blog heb geschreven: om die mensen te overtuigen dat de service layer nog steeds een waardevolle laag is.

ps:
Dat is trouwens ook de reden dat geen probleem heb met de naam manager voor applicatie-services. Bij ons weet iedereen dan meteen over welke laag het gaat.

[ Voor 12% gewijzigd door Alarmnummer op 02-06-2006 10:37 ]

[Michali]

Ok, bedankt. Het boek van fowler heb ik ook overigens. Ik ga het deel over service layers nog maar eens goed bekijken dan