DDD en software migratie patronen

 
06 januari 2009

Met dank aan André Boonzaaier voor het aanzwengelen van dit interessante en zeer belangrijke onderwerp, wil ik graag zijn betoog aanvullen met de introductie van een migratiestrategie die een belangrijke plaats inruimt voor de domeingedreven aanpak, zoals wij die bij Sogyo veel gebruiken.

DDD en legacy migratie worden niet vaak gecombineerd, terwijl er grote voordelen te behalen zijn. DDD is echt niet alleen geschikt voor “green-field” projecten!

Bij een domeingedreven aanpak wordt begonnen met het maken van een domein model van de legacy applicatie, of een onderdeel daarvan dat als kandidaat wordt gezien voor vervanging. Deze exercitie lijkt een omvangrijke te zijn, maar dat is niet de bedoeling. De mate van detaillering van dit model moet zodanig zijn dat het in ongeveer een twaalftal mandagen afgerond kan zijn. De inzet van domein deskundigen zowel als applicatie deskundigen die de legacy goed kennen is hiervoor benodigd. Het domein model wordt echter niet gemaakt op basis van de bestaande (legacy) applicatie, maar uitsluitend op basis van de door die applicatie geleverde functionaliteit. We proberen een zo “schoon” en technologie onafhankelijk mogelijk model te maken. Hiervoor maken we gebruik van eXploratory Modelling en use case modelleren. Het domein model zelf is echter geen use case model, maar een class diagram met objecten en verantwoordelijkheden.

Na het maken van het domein model wordt hierin een gebied gedemarkeerd dat als eerste gemigreerd gaat worden. Een schematische weergave van deze activiteit kunt u in de figuur hieronder zien.

Domain Model

Domain Model

We maken dus een schema van wat gemigreerd dient te worden in het domein model, en in het geheel niet in de bestaande legacy applicatie! Dit is een belangrijk aspect van deze strategie. Hierdoor vermijden we een groot aantal problemen en complexiteit.

Na het markeren is de beurt aan de experts van de legacy. Deze krijgen de opdracht om op basis van de semantiek van de rode lijntjes, dat zijn die lijnen die over de grenzen van het gedemarkeerde gebied heen gaan (en dus de dependencies met de rest van de legacy aangeven), alle onderdelen in de bestaande legacy te identificeren die overeen komen met die semantiek. Dit kunnen vele honderden plaatsen zijn, vooral in legacy die in de loop der jaren verworden is tot spaghetti. Toch heeft de ervaring die wij met deze techniek hebben opgedaan bewezen dat ook deze exercitie complexer lijkt dan hij is. Men blijkt in staat te zijn, ook omdat men duidelijk weet wat te zoeken, dit in zeer korte tijd te doen.

Hierna worden twee activiteiten uitgevoerd:

  1. de bestaande legacy wordt op de plaatsen zoals hiervoor beschreven aangepast. Dit is een simpele en niet-destructieve aanpassing: er wordt een eenvoudige test toegevoegd die kijkt of het betreffende onderdeel, functie of module, wordt aangeroepen door de “nieuwe” wereld, of door de “oude” (= de legacy zelf). De aanpassing bestaat daarin dat wanneer het vanuit de “nieuwe” wereld komt, de executie moet stoppen (immers dit zal voortaan door het nieuwe component opgepakt gaan worden!). Anders doet het systeem gewoon wat het al deed.
  2. het nieuwe component dat het gedemarkeerde gebied implementeerd wordt gebouwd

Er valt nog veel te zeggen over dit onderwerp. Wat ik wil benadrukken is dat als u de indruk heeft dat deze aanpak lijkt op een recept ik dit meteen wil beamen. Recepten werken vaak niet omdat de werkelijkheid weerbarstiger is dan men zich van tevoren kan voorstellen. In dit geval hebben wij zelf vaak versteld gestaan van de mate waarin een complex en risicovol traject als legacy migratie werd geholpen door een schijnbaar bedrieglijk eenvoudige aanpak.

Voor meer informatie kunt u ook dit artikel (in het Engels) lezen.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Architectuur


Reactie

  • Rob, inderdaad, dit is een hele goede en praktisch toepasbare analysemethode in mijn optiek.

    Mijn verhaal was wat technischer van aard, da’s meer de invulling erna. Helaas is het niet altijd mogelijk om in dezelfde ‘laag’ te koppelen tussen de legacy en de nieuwbouw; o.a. afhankelijk van oud en nieuw platform en andere constrains.

    Geplaatst op 18 januari 2009 om 23:24 Permalink