Best practices Domain Driven Design icm monoliet

[Furion2000]

In het kader van zelfonwikkeling als junior java ontwikkelaar ben ik bezig met een project om doormiddel van DDD (Domain Driven Design) van een grote monoliet modules te maken. Met het boek van Eric Evans over DDD is er al een module gemaakt en ben ik nu vooral op zoek naar ervaringsdeskundige.

Zijn er al veel bedrijven die ons voor zijn gegaan met dit idee en hier al wat jaren ervaringen mee hebben?

Ik krijg vooral het idee dat bedrijven de monoliet als 1 module beschouwen en zodra er een nieuw domein ontstaat er de mogelijkheid zich voor doet er een module naast de monoliet word gebouwd. Ook vooral omdat zodra je klaar zou zijn het al weer legacy code zou zijn.

Zijn er dus mensen met best practices op gebied van DDD ontwikkeling tegen een bestaande monolitische architectuur? De talloze tegenargumenten zijn wel bekend, maar de tips om te leren omgaan met DDD i.c.m. een monoliet zou op dit moment waardevol kunnen zijn.

Alvast bedankt.

[Hydra]

Niet direct gerelateerd maar een manier om van een legacy applicatie naar een nieuwe architectuur te gaan is het strangler pattern. Je legt een laag over de applicatie waarbij je steeds meer functionaliteiten omhangt naar de 'nieuwe' architectuur. Dit voorkomt dat je in 1 keer big bang over moet gaan.

Afgezien daarvan; ik vind het lastig iets zinnigs te zeggen over je vraag. DDD is vaak een uitgangspunt in microservice architecturen. Dus ja, dat wordt vaak toegepast.

[CyBeRSPiN]

Je lijkt de discussie te willen skippen, maar ben benieuwd: wat is er in jouw optiek mis met een monoliet? Microservices lijken vooral een organisatorisch probleem op te lossen voor extreem snel groeiende startups: er zijn dan zoveel wijzigingen tegelijkertijd nodig dat een centrale sturing van de architectuur een bottleneck vormt. De valkuil is dat iedereen opkijkt naar Facebook/Uber/Netflix/Spotify als het Grote Voorbeeld, maar die zijn gaandeweg op die architectuur uitgekomen (als oplossing voor hun inmiddels monsterlijke omvang).
Het (enorme) nadeel is dat je een brei van losse services krijgt die per stuk allemaal simpel lijken, maar in de praktijk een enorme complexiteit geven in de samenstelling ervan.
Je hebt dan een fors DevOps team nodig om dat allemaal in goede banen te leiden.

En de angst voor "legacy code" begrijp ik niet, wat versta je daar precies onder?
Je wilt toch iets maken dat voor langere tijd zonder fundamentele wijzigingen kan doen waarvoor het bedoeld is, niet perse altijd het framework-du-jour willen draaien met bijbehorende verloren tijd in het weer opnieuw refactoren van al bestaande functionaliteit?

[Sandor_Clegane]

Furion2000 schreef op dinsdag 13 november 2018 @ 15:08:
In het kader van zelfonwikkeling als junior java ontwikkelaar ben ik bezig met een project om doormiddel van DDD (Domain Driven Design) van een grote monoliet modules te maken. Met het boek van Eric Evans over DDD is er al een module gemaakt en ben ik nu vooral op zoek naar ervaringsdeskundige.

Zijn er al veel bedrijven die ons voor zijn gegaan met dit idee en hier al wat jaren ervaringen mee hebben?

Ik krijg vooral het idee dat bedrijven de monoliet als 1 module beschouwen en zodra er een nieuw domein ontstaat er de mogelijkheid zich voor doet er een module naast de monoliet word gebouwd. Ook vooral omdat zodra je klaar zou zijn het al weer legacy code zou zijn.

Zijn er dus mensen met best practices op gebied van DDD ontwikkeling tegen een bestaande monolitische architectuur? De talloze tegenargumenten zijn wel bekend, maar de tips om te leren omgaan met DDD i.c.m. een monoliet zou op dit moment waardevol kunnen zijn.

Alvast bedankt.

Wat bedoel je met modules? Zijn dat verschillende bounded contexts?

Of zijn het modules die bij dezelfde bounded context horen? Dan kun je je afvragen of het niet gewoon zo allemaal wel prima is. En doe je dan ook CQRS/Event sourcing?

[Furion2000]

@Hydra

Strangler pattern ziet er interessant uit en zou het 'vage' domain gedeelte in DDD, voor mij, vooral ook omdat ik nog niet heel veel kennis heb over het domein, behapbaar houden. Want als ik het goed begrijp kun je services eruit slopen en er naast zetten of nieuwe services er naast zetten. Ga als ik tijd heb even verder lezen hierover, want deze was anders nog trager.

Off: bijna een jaar geleden hielp je mij nog met informatie over starten als ontwikkelaar en leer op dit moment ontzettend veel over architectuur, maar vaak gaat het mij op het moment van lezen/horen al te snel en moet ik weer een stapje terug doen, mijzelf inlezen en weer verder erover nadenken

@CyBeRSPiN

Ik denk ook dat dat deels het geval is, puur omdat het gevoel om te vernieuwen sterk aanwezig is en het op dit moment al een grote bowl of spaghetti is. De grootste wens is ook om een beetje order in deze spaghetti te brengen, omdat zelfs de langst zittende ontwikkelaars soms de weg kwijt raken in de laatste jaren en het onderhoud steeds intensiever word.

Ik noem het legacy code omdat er nog een groot gedeelte meer dan 15 jaar oud is en er over de jaren erg veel fixes over heen zijn gegaan die gaten hebben gedicht, maar niet de complete oplossing vormen. Nu is het management sinds een jaar ook overtuigd geraakt dat er dingen ECHT overnieuw weggezet moet worden en omdat er nu tijd en geld word vrijgemaakt willen iedereen hier graag natuurlijk goed gebruik van maken.


@Sandor_Clegane

Bounded context als in; we hebben een module weggezet die de invoice context bevat. CQRS, Event Sourcing doen we niet, alleen na deze tryout word het wel steeds vaker events genoemd als oplossing voor de moeilijkheden de we ondervonden.

Misschien moet ik de vraag dan aanpassen, is een spaghetti monoliet van zo'n 20 jaar nog te redden met DDD of zijn er betere oplossingen? Zo ja, heeft iemand ervaring met zo'n project of kent iemand die hier aan meegewerkt heeft?

[Swedish Clown]

Furion2000 schreef op donderdag 15 november 2018 @ 09:41:
Misschien moet ik de vraag dan aanpassen, is een spaghetti monoliet van zo'n 20 jaar nog te redden met DDD of zijn er betere oplossingen? Zo ja, heeft iemand ervaring met zo'n project of kent iemand die hier aan meegewerkt heeft?

Is het te redden? Jazeker maar DDD is niet je silver bullet voor je "probleem". (Ondanks dat voor mij niet helemaal duidelijk is wat je probleem daadwerkelijk is?). Ik heb de afgelopen 3 jaar gewerkt aan monolith en een event stream opgezet met de rest van het team. Doel was om andere teams de mogelijkheid te geven om taken die de monolith op dit moment uitvoert, over te nemen.

Is het te doen? Jazeker en heb daar ruim 2 jaar ervaring mee. Is dat uit te leggen in een forum post waar je daadwerkelijk wat aan hebt? Absoluut niet. Als die kennis niet in huis is, haal die kennis dan in huis want dit zal een project worden waar je nog wel een tijdje mee zoet zal zijn

<sub>Ik krijg een beetje kriebels van dit topic. Ik heb het idee dat "monolith" en "15 jaar" per definitie wordt bestempeld als slecht. Ik heb geen inzage in de code maar dat hoeft zeker niet zo te zijn.

De monolith waar ik aan werk is 13-14 jaar oud en heeft in 2018 al 129 releases gehad. Een release bevat gemiddeld een branch of 5-10 en het gaat dan niet alleen om bugs maar ook enorme features. Er is echter de afgelopen jaren heel veel tijd gestoken in het opzetten van een stabiele pipeline voor zowel development als voor het testen van de release candidate. Combineer dat met een aandacht voor refactoren en je kan met een gerust hart refactoren zonder dat je bang hoeft te zijn dat je de boel sloopt. De code base blijft groot wat met name nadelen heeft voor het onboarden van nieuwe medewerkers maar verder is het niet anders.

Besteed aandacht aan je infrastructuur, je tests en zorg dat de boel stabiel is. Daarna kan je gaan kijken naar DDD en verantwoordelijkheden van de monolith van je afschuiven. Doe je dat niet, dan ga je op het #yolo pad en heb je kans op een grotere puinhoop dan waar je (volgens jou) nu op zit.

Het alternatief van microservices is dat als één van de grote jongens een feature wil, dat ik een PR in 7 repo's aan het uitvoeren ben in zowel NodeJS, Java en Erlang. Daar wordt je ook niet altijd even blij van</sub>

[Voor 40% gewijzigd door Swedish Clown op 15-11-2018 13:23]

[PWSteal]

Brakkie41 schreef op donderdag 15 november 2018 @ 10:07:
[...]

<sub>Ik krijg een beetje kriebels van dit topic. Ik heb het idee dat "monolith" en "15 jaar" per definitie wordt bestempeld als slecht. Ik heb geen inzage in de code maar dat hoeft zeker niet zo te zijn.

De monolith waar ik aan werk is 13-14 jaar oud en heeft in 2018 al 129 releases gehad. Een release bevat gemiddeld een branch of 5-10 en het gaat dan niet alleen om bugs maar ook enorme features. Er is echter de afgelopen jaren heel veel tijd gestoken in het opzetten van een stabiele pipeline voor zowel development als voor het testen van de release candidate. Combineer dat met een aandacht voor refactoren en je kan met een gerust hart refactoren zonder dat je bang hoeft te zijn dat je de boel sloopt. De code base blijft groot wat met name nadelen heeft voor het onboarden van nieuwe medewerkers maar verder is het niet anders.

Besteed aandacht aan je infrastructuur, je tests en zorg dat de boel stabiel is. Daarna kan je gaan kijken naar DDD en verantwoordelijkheden van de monolith van je afschuiven. Doe je dat niet, dan ga je op het #yolo pad en heb je kans op een grotere puinhoop dan waar je (volgens jou) nu op zit.

Het alternatief van microservices is dat als één van de grote jongens een feature wil, dat ik een PR in 7 repo's aan het uitvoeren ben in zowel NodeJS, Java en Erlang. Daar wordt je ook niet altijd even blij van</sub>

Ik denk zelfs dat je jezelf een paar keer achter de oren moet krabben voordat je ook maar aan microservices gaat beginnen. Het ontwikkelen van zo een architectuur heeft zijn eigen uitdagingen, en zolang deze niet goed worden aangepakt gaat het gegaranderd een drama worden. Hoe ga je bijvoorbeeld om met netwerk falen, het uitvallen van een instantie van een service, monitoring, logging etc etc. Zaken die in een monolith vele malen eenvoudiger zijn of zelfs niet aan de orde zijn.

Ik werk zelf ook aan een monolith, welke al een jaartje of 5 aan gesleuteld wordt, en kan alleen benadrukken dat het onderhoud aan architectuur, werkende (en nuttige) tests, stabiliteit en release automatisering vele malen belangrijker is dan de keuze van microservices vs monolith.

De infrastructuur moet uiteindelijk een middel zijn om een doel te bereiken, zoals schaarbaarheid, hoge IOPS, failure resistance en noem maar op wat voor jouw specifieke product belangrijk is. In elke organizatie zijn er unieke wensen/eisen en uitdagingen, daarom zal de aanpak ook overal anders zijn. Wat bij partij A goed werkt, kan bij party B heel anders uitpakken.

@Furion2000

Zijn er dus mensen met best practices op gebied van DDD ontwikkeling tegen een bestaande monolitische architectuur? De talloze tegenargumenten zijn wel bekend, maar de tips om te leren omgaan met DDD i.c.m. een monoliet zou op dit moment waardevol kunnen zijn.

In DDD is een fysieke scheiding van domeinen geen verplichting, een enkele applicatie opdelen in domeinen zie je dan ook regelmatig voorbijkomen. Echter is het hierbij wel oppassen dat de grenzen van je domein duidelijk blijven, bij een micro-service heb je een fysieke scheiding waardoor dit wat natuurlijker gaat.

Daarnaast zou ik beginnen met je af te vragen wat je met micro-services wilt gaan oplossen. Tegen welk probleem loop je aan met de huidige architectuur, hoe gaan micro-services dit oplossen? Vraag je altijd af waarom je zulke grote beslingen wilt gaan doen, en verwar niet het doel en het middel. Dit zie ik persoonlijk erg vaak fout gaan om mij heen.

Een heel goed voorbeeld vanuit mijn eigen ervaring;
In mijn organizatie hebben we in principe 3 monoliths draaien (1 JS frontend, 1 .NET backend en een oude MVC app), en daarnaast nog paar losse webservices. Eerst hadden we alleen de MVC app (5 jaar terug) en zijn toen vanaf scratch begonnen omdat het oude gedeelte onbeheersbaar was geworden en we niet meer konden voldoen aan de business cases met dat systeem.

Vanwege 'performance-redenen' hebben de toenmalige ontwikkelaars bedacht dat we een distributed cache nodig hadden in de backend. Dit is uiteindelijk zonder goed te redeneren waarom we het nodig hadden blindelings geimplementeerd. Uiteindelijk is het implementeren van de cache-laag een doel geworden voor vele ontwikkelaars, degene die het bedacht hadden doen het ook, dus het zal wel belangrijk zijn. Zelfs data die maar 1~2x per dag opgevraagd werd, wordt in die cache gestopt. Door de gehele applicatie zit nu die laag, en tot op de dag van vandaag heeft het ongeveer het volgende opgelevert;

-Bugs vanwege cache-invalidation issues.
-Geen merkbare performance verbetering, op sommige delen was simpelweg de sql-query nog beter qua performance.
-Ingewikkelder voor maintenance doeleinden, hoe bijvoorbeeld een handmatige data correctie doorvoeren. Dan moet ook de cache invalidate worden.
-Extra dependency naar een 3rd party component.

Ik bedoel hiermee te zeggen; laat je architectuur of een bepaalde techniek niet je doel worden. Gebruik het als een middel om de doelen te behalen die voor jouw unieke case belangrijk zijn.

[Swedish Clown]

Edwin__ schreef op maandag 19 november 2018 @ 21:36:
[...]

Hoe ga je bijvoorbeeld om met netwerk falen, het uitvallen van een instantie van een service, monitoring, logging etc etc. Zaken die in een monolith vele malen eenvoudiger zijn of zelfs niet aan de orde zijn.

De zaken die je hier opnoemt zijn tot op zekere hoogte zeker van de orde voor een monolith. Sterker nog, netwerk|service failure zorgt er dan voor dat de hele boel op ze flikker gaat. Monitoring en logging kan zijn relatief gemakkelijk op te lossen met tools als Splunk. Kost een paar centen, maar het levert een hoop op. Bij een grotere monolith kan logging en monitoring (alarms) zelfs een een bottleneck en ze eigen challenges vormen

Netwerk/service failure valt in sommige gevallen prima af te hangen via Kafka. Bij ons wordt bijvoorbeeld een hop via Kafka gebabbeld zolang er geen real time connectie nodig is. Avro schema dertussen en je hebt (naar mijn ervaring) een API die zich ook nog gemakkelijk laat ontwikkelen vanwege de schema evolution die Avro biedt. L

Kort gezegd, het opbreken van een Monolith is een zware taak en je zal je als organisatie heel hard moeten afvragen hoe ver je wilt gaan en een duidelijk doel voor ogen moeten hebben over het waarom je dat wilt. Dus TS, wat is het probleem dat je wenst op te lossen?

(Met de rest van je post trouwens volledig eens en zo te lezen zitten we aardig op één lijn )

[PWSteal]

Brakkie41 schreef op maandag 19 november 2018 @ 22:10:
[...]


De zaken die je hier opnoemt zijn tot op zekere hoogte zeker van de orde voor een monolith. Sterker nog, netwerk|service failure zorgt er dan voor dat de hele boel op ze flikker gaat. Monitoring en logging kan zijn relatief gemakkelijk op te lossen met tools als Splunk. Kost een paar centen, maar het levert een hoop op. Bij een grotere monolith kan logging en monitoring (alarms) zelfs een een bottleneck en ze eigen challenges vormen

Netwerk/service failure valt in sommige gevallen prima af te hangen via Kafka. Bij ons wordt bijvoorbeeld een hop via Kafka gebabbeld zolang er geen real time connectie nodig is. Avro schema dertussen en je hebt (naar mijn ervaring) een API die zich ook nog gemakkelijk laat ontwikkelen vanwege de schema evolution die Avro biedt. L

Kort gezegd, het opbreken van een Monolith is een zware taak en je zal je als organisatie heel hard moeten afvragen hoe ver je wilt gaan en een duidelijk doel voor ogen moeten hebben over het waarom je dat wilt. Dus TS, wat is het probleem dat je wenst op te lossen?

(Met de rest van je post trouwens volledig eens en zo te lezen zitten we aardig op één lijn )

Point taken wat de betreft netwerk/service failure Wat betreft monitoring/alterting zijn er ook een hoop gratis tools beschikbaar. Bijvoorbeeld Prometheus is een mooi pakket en kan met plugins worden uitgebreid.

[Nick_S]

Ik heb vorige week een mooie talk gezien op Devoxx over System of Systems, welke mij ook weer aan het nadenken heeft gezet over onze monoliet, en onze huidige trend naar microservices. Misschien ook voor jou interessant om te kijken? Hij heeft in ieder geval goed naar DDD gekeken, want de termen, zoals bounded context, komen regelmatig langs.

[Knippr]

CyBeRSPiN schreef op dinsdag 13 november 2018 @ 16:10:
Je lijkt de discussie te willen skippen, maar ben benieuwd: wat is er in jouw optiek mis met een monoliet? Microservices lijken vooral een organisatorisch probleem op te lossen voor extreem snel groeiende startups: er zijn dan zoveel wijzigingen tegelijkertijd nodig dat een centrale sturing van de architectuur een bottleneck vormt. De valkuil is dat iedereen opkijkt naar Facebook/Uber/Netflix/Spotify als het Grote Voorbeeld, maar die zijn gaandeweg op die architectuur uitgekomen (als oplossing voor hun inmiddels monsterlijke omvang).
Het (enorme) nadeel is dat je een brei van losse services krijgt die per stuk allemaal simpel lijken, maar in de praktijk een enorme complexiteit geven in de samenstelling ervan.
Je hebt dan een fors DevOps team nodig om dat allemaal in goede banen te leiden.

En de angst voor "legacy code" begrijp ik niet, wat versta je daar precies onder?
Je wilt toch iets maken dat voor langere tijd zonder fundamentele wijzigingen kan doen waarvoor het bedoeld is, niet perse altijd het framework-du-jour willen draaien met bijbehorende verloren tijd in het weer opnieuw refactoren van al bestaande functionaliteit?

Prima reactie. Iedereen denkt tegenwoordig Facebook of Netflix te zijn, terwijl een monoliet zelfs tot op enterprise schaal vaak nog prima te doen is. Aan de front-end kant zie je het ook, loeizware frameworks omdat men denkt een interactieve UI te hebben a la Facebook, maar vaak is dat niet zo.

Als aanvulling op microservices problematiek bij bedrijven die er niet goed over nadenken: honderden microservices die elkaar aanroepen. Daar ga je dus met je architectuur, zelfde puinhoop, nu nog moeilijker te beheersen.

[Furion2000]

Aandachtig jullie reacties gelezen en wat het meest mij bij blijft zijn de volgende opmerkingen.

Het doel niet verwarren met het middel.
Het doel in deze is een verwarrende monoliet zonder documentatie, minder verwarrend te maken. Nieuwe mensen(junior-senior) kunnen vaak niet goed zien wat de aanpassing helemaal inhoud en wat er allemaal kapot kan gaan. De oplossing die men vooral wil zijn modules en in die slag gelijk meer documentatie erbij. Modules met daarin de bounded contexts@Brakkie41 want dit was jou vraag

'Iedereen' denkt tegenwoordig Facebook of Netflix te zijn
Deels waar misschien, maar persoonlijk kreeg ik al tijdens mijn traineeship te horen dat bedrijven zoals de Rabobank alleen het jasje super hip houden en er op de achtergrond niet veel of snel verandering plaatsvind. Na een presentatie op JFall schijnt dit ook zo te zijn, more or less, en worden de nieuwe features gebruikt als poc.

"Besteed aandacht aan je infrastructuur, je tests en zorg dat de boel stabiel is." en leesbaar voor nieuwe mensen.

@Nick_S Ik zal hem gaan kijken, ben benieuwd. Cheers.

[Voor 3% gewijzigd door Furion2000 op 21-11-2018 11:47]