In een vorig artikel heb ik het over architectuur principes in OutSystems gehad. Met name high-cohesiën en low coupling zijn voor mij basisprincipes. Een domain driven design (DDD) is een goede manier om dit te bereiken.
Domain Driven Design(DDD)
In een domain driven design is er high-cohesiën binnen het domein en low-coupling tussen de domeinen. Elk domein heeft zijn eigen lifecycle, ontwikkelaarsteam, business eigenaar, en of business sponsor. Voorbeelden van specifieke business domeinen zijn, HR, Finance, CRM, Logistiek etc. Op het moment dat domeinen vrij groot zijn, kun je ze onderverdelen in sub-domeinen (bijv. Finance in inkoop, grootboek, salaris etc.)
Binnen een domein is de samenhang en de afhankelijkheid tussen verschillende business concepten groot. Transacties gaan vaak over meerdere entiteiten. Tussen verschillende domeinen is de samenhang en afhankelijkheid lager.
Public Server actions vs Service actions
Server actions en service actions lijken veel op elkaar. Maar er zijn een aantal significante verschillen. Op het moment dat je meerdere server actions aanroept is dit dezelfde transactie. Elke service action is een nieuwe losse transactie. Bij publicatie van een module met een service action is deze meteen beschikbaar, je hoeft afhankelijke modules niet opnieuw te publiceren. Bij een public server action moet dit wel.
Wanneer gebruik je nu welke?
Kijk je naar de verschillen tussen public server actions en service actions in combinatie met de architectuur principes, dan gebruik je binnen een domein server actions en tussen domeinen service actions.
Maar wat als?
Maar wat als je nu van een domein in een ander domein meerdere updates wil doen en dit in een transactie moet? Dan creëer je een service action waarin je in een keer alle gegevens meegeeft voor alle updates en roep je in de service action meerdere server actions aan.
Maar wat als ik alleen data wil tonen (van meerder entiteiten)? Hiervoor zijn twee mogelijkheden. Creëer een service action die de gewenste geaggregeerde informatie teruggeeft, op het moment dat er veel verschillende aggregaties nodig zijn, zorgt dit voor veel service actions en werk. De tweede mogelijkheid is de entiteiten read only beschikbaar te maken, dit verhoogt wel de afhankelijkheid tussen domeinen.
Marc Wetters
Senior Software Architect at LowQode