We zien steeds meer organisaties van monolithische applicaties naar modulaire systemen bewegen. Een uitdaging die binnen dergelijke distributed systemen komt kijken is de manier waarop de modules onderling communiceren. Een veelgebruikte oplossing voor asynchrone communicatie, is om een messaging service zoals RabbitMQ te gebruiken. Wat je dan in de praktijk bij veel teams ziet is een oplossing zoals in het onderstaande diagram vereenvoudigd weergegeven:

Een actie op service 1 waarop een andere service moet reageren wordt als event op de queue gezet. Service 2 implementeert een listener die het event van de queue haalt en vervolgens verwerkt. Zolang de applicatie relatief klein is, functioneert deze manier van werken prima. Het wordt echter een stuk lastiger naarmate de applicatie groeit en de services door verschillende teams beheerd worden:

• Om de beschreven action te implementeren wordt het team dat service 1 beheert afhankelijk van een listener die door een ander team gebouwd moet worden.
• Er ontstaat een wederzijdse afhankelijkheid van de beide services van 1 message queue, welk team is nu verantwoordelijk voor events die niet opgepakt kunnen worden?
• Events afkomstig van service 1 komen niet via het publieke endpoint van service 2 binnen, maar via een achterdeur. Dit is een aanzienlijke verhoging van de complexiteit en kan grote problemen geven bij versie updates.
• Het documenteren van publieke REST api’s is veel eenvoudiger dan queue berichten.

Al met al de nodige redenen om af te stappen van de bovenstaande implementatie van een message broker laag.

Een alternatieve implementatie
Met een aantal relatief eenvoudige aanpassingen is het mogelijk om de services beter te isoleren en teams onafhankelijk van elkaar te laten werken:

• Services communiceren alleen met elkaar via de publieke endpoints, wat de complexiteit van de communicatie drastisch verlaagd.
• Waar asynchrone communicatie nodig is wordt een message broker gebruikt, echter de service zelf pakt deze asynchrone events op en pushed het bericht door naar andere service endpoints.
• De enige afspraak voor samenwerking tussen services is via hun REST contract. Teams hebben meer vrijheid om eigen tools en technologie te kiezen waardoor meer maatwerk ontstaat.

Welke winst hebben we nu geboekt:

• Teams zijn niet afhankelijk van andere teams voor het opleveren van features (mits er geen volledig nieuwe endpoints nodig zijn, maar dat is meestal niet het geval).
• Een team is volledig verantwoordelijk voor het afhandelen van een action inclusief het aftrappen van vervolgstappen.
• Het is volstrekt helder welk team verantwoordelijk is voor de queue van service 1.
• Het is relatief eenvoudig om service 1 inclusief de propagatie geïsoleerd automatisch te testen inclusief het afhandelen van foutmeldingen die van service 2 terugkomen.

Auteur: Menno Jongerius, Bergler Competence Center © 2018

Dit is het derde artikel in de serie over Domain Driven Design.

• Artikel 1 : Introductie
• Artikel 2: Het model

Om het begrip rond aggregates, entiteiten en value objecten goed te begrijpen is begrip nodig van de zogenaamde “life cycle” van objecten in het algemeen. De DDD manier beschrijft de status van een object zijnde: “actief”, “verwijderd” of “gearchiveerd”.

Een “actief” object is in het geheugen geladen (bijvoorbeeld uit een database) en wordt actief mee gewerkt of gebruikt om entiteiten binnen een bounded context te benaderen.

Een “verwijderd” object krijgt deze status eigenlijk middels een “onzichtbaar” vlag omdat entiteiten eigenlijk nooit verwijderd worden (is overigens een uitdaging in het perspectief van GDPR en “mij vergeten”).

Een “gearchiveerd” object is opgeslagen en niet geladen in het geheugen van de applicatie.

Bovenstaande is door Eric Evans grafisch weergegeven in zijn boek “Domain Driven Design, tackling the complexity in the heart of software”.

Moderne software oplossingen bevatten snel diepgaande structuur van objecten middels verschillende lagen. In aanvulling hierop worden software oplossingen steeds meer gebruikt via verschillende apparaten en kunnen deze draaien op verschillende besturingssystemen. Veel gebruikers muteren gegevens tegelijkertijd hierdoor. De uitdaging is daarom om de waarheid van de objecten te garanderen. Deze consistentie van veranderingen “eventual consistency” is DE uitdaging van DDD gedreven oplossingen.

Consistentie wordt bepaald via een verzameling van regels, in DDD termen “invariants” genoemd. Deze “invariants” moeten op 1 plek worden vastgelegd. Zij bepalen de samenhang van de objecten in de bounded context en zorgen ervoor dat 1 waarheid blijft bestaan. Die ene plek is het hoofd object in de bounded context. Dit hoofd object wordt de aggregate root genoemd. Doordat dit type object verantwoordelijk is om de “invariants” te bewaken, moet het de rol spelen van de “poortwachter” voor de bounded context.

In andere woorden, alleen via de aggregate root kan de bounded context en haar inhoud worden aangesproken en worden gewijzigd.

De volgende regels worden in acht genomen voor aggregates en hun bounded contexts:

• De aggregate zorgt voor consistentie binnen de bounded context. Dit betekent dat het verwerken van gerelateerde objecten binnen 1 transactie moet plaatsvinden
• De aggregate objecten hebben een identiteit die over alle bounded contexten geldt. Op deze manier zijn uitwisselingen mogelijk van gegevens tussen de bounded contexten. Overige entiteiten binnen een bounded context, hebben een lokale identiteit. Er bestaat geen garantie dat voor entiteiten met dezelfde naam en identiteit maar in verschillende bounded contexten, zij ook identiek zijn. Immers, bijvoorbeeld de entiteit “Person” kan in de bounded context van Employee totaal iets anders voorstellen als in de bounded context Sales
• De opbouw van de structuur van objecten uit een opslag, gebeurt altijd via de aggregate. De aggregate heeft kennis van de interne structuur in de bounded context
• Een aggregate kan referenties hebben naar andere aggregates in andere bounded contexten
• Zodra er wijzigingen worden aangebracht via de aggregate, moeten deze onmiddelijk worden verwerkt in de opslag en moeten alle regels voor consistentie zijn nageleefd

Aggregates is dus een speciaal object in DDD. Conform de “ubiquitous language” is de aggregate dus een entiteit met speciale eigenschappen en gedrag. Andere objecten binnen de bounded context zijn dus of reguliere entieiten of value objects.

Value objects, weer een abstracte term die toelichting vereist. Het verschil tussen een entiteit en een value object is dat de laatste geen unieke identiteit heeft. Ook is een value object onwijzigbaar. Waarom zou je dergelijke objecten gebruiken en hoe pas je deze toe? Een voorbeeld wordt gebruikt om deze vragen te beantwoorden.

Neem de bounded context van OrderManagement (fictief voorbeeld). Binnen deze bounded context is de Order de aggregate en deze heeft een collectie van OrderLine objecten. Het OrderLine object heeft informatie nodig over het Product. Product wordt in dit voorbeeld beschreven door een naam en SKU code. Stel nu dat deze eigenschappen als eenvoudige eigenschappen in de OrderLine worden ondergebracht. Niets weerhoud een onwetende ontwikkelaar ervan de productnaam aan te passen van de Orderline. Echter, dit is niet toegestaan omdat men zich kan voorstellen dat de naam en SKU code bij elkaar horen.

Om dit te voorkomen wordt Product gebruikt als value object. Indien het bestaande Product op de OrderLine aangepast dient te worden, dan passen we niet de eigenschappen van Product aan, maar vervangen we de huidige instantie van Product door een nieuwe instantie van Product.

In het laatste artikel welke na de zomervakantie zal verschijnen, wordt een case beschrijving gebruikt om alle beginselen die in de artikelen tot dusver aan bod zijn gekomen, te implementeren in een .Net solution.

Auteur: Arjen Kraak, Bergler Competence Center © 2018

Op 19 juni jongstleden organiseerde Bergler de thema-middag Domain Driven Design en (micro)services in de praktijk. We zien de afgelopen jaren steeds meer organisaties in meer of mindere mate agile werken, waarbij continuous integration en continuous deployment belangrijker worden. Om succesvol en snel aanpassingen in de markt te kunnen zetten is een behapbare en modulaire opzet van je software een must.

Tijdens deze sessie gingen we in op verschillende facetten om te komen tot modulaire software. We keken naar de basis principes van domain driven design en op welke manier je de boundries van de modules kunt bepalen. Verderop gingen we in op de effecten van een modulaire applicatie op je architectuur en als toonden we een aantal strategieen om van een bestaande legacy applicatie te komen tot een modulaire applicatie.

Vier sprekers zorgden voor een overvolle avond, de video’s kun je hieronder bekijken.

We zien steeds meer organisaties monolitische legacy applicaties ombouwen tot modulaire applicaties. Tijdens deze sessie gaan we in op de vraag waarom domain driven design je kan helpen bij het opzetten van losgekoppelde modules. Arjen Kraak introduceert DDD in gewoon nederlandse termen om met de aanwezigen dezelfde basiskennis te delen.

Tijdens deze sessie staan we stil bij Eventstorming en hoe je deze methodiek kunt toepassen om in korte tijd een domein in kaart te brengen en op kunt splitsen in modules. Patrick Bes vertelt over deze workshop-methodiek om op een snelle en leuke manier een business domein te analyseren om tot een DDD design te kunnen komen.

Tijdens deze sessie van Menno Jongerius gaan we in op een aantal basisprincipes achter domain driven design en hoe deze vertalen naar architectuur en losgekoppelde modules.

Sjaak Spiegels van Voogd & Voogd spreekt openhartig over de ervaringen bij het toepassen van DDD en presenteert de patronen van technieken die zij hebben toegepast.

En, heb je de smaak te pakken?

Meld je dan aan voor ons komende event op 13 november aanstaande: DevOps, continous delivery en distributed systems (Expertise Center). Nadere informatie volgt snel. Inschrijven kan via deze pagina.

Soms loop je in je zoektocht naar een framework of, zoals in dit geval bij toeval, tegen een framework aan waarvan je denkt: Ja, dit is leuk en handig om te gebruiken in mijn ontwikkel projecten. Bij mij was dat het geval toen ik per ongeluk tegen een cursus over het SpecsFor BDD framework aanliep tijdens het scannen van interessante cursussen op PluralSight).

In het vorige artikel is DDD geïntroduceerd. Hierbij is beschreven wat de “why” is van DDD. Dit artikel zal dieper ingaan over het “wat” van DDD. Het “wat” van DDD is het middel om tot het doel te komen. Dit middel is het komen tot een “model”.

Wat is een “problem domain”?
De term “probleemdomein” wordt vaak aangeduid in DDD voor het definieren van een functioneel gebied in een organisatie. Een applicatie zal nimmer alle processen ondersteunen van de organisatie. Denk bijvoorbeeld aan applicaties voor personeelszaken en inkoop. Organisaties van enige omvang hebben hiervoor altijd verschillende applicaties. Personeelszaken is bijvoorbeeld een “probleemdomein”.

Er wordt een “model” opgesteld. Wat is een “model”?
Een groot denker en pionier op het terrein van Domain Driven Design, Eric Evans zegt over het “model” het volgende: “every model represents some aspect of reality or an idea of interest. A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving a problem at hand and ignores extraneous detail”

Een architect en/of analist faciliteert het opstellen van het model. Wat heb je dan? Het model beschrijft het “uiterlijk” en “gedrag” van het gekozen probleem domein. Het “uiterlijk” is de verzameling van gegevens die van belang zijn. Hierbij is ook de relatie tussen deze gegevens interessant. Het “gedrag” beschrijft de processtappen en gebeurtenissen die met/op deze gegevens plaatsvinden. Je kan het ook menselijk maken. Het gedrag is wat van buitenaf wordt gezien. Dit gedrag heeft intentie/motivatie, dat zijn de gegevens. Binnen DDD wordt gedrag beschreven als een verzameling van “events” en de intentie als een verzameling van “entiteiten”. De verzameling van deze beschrijvingen worden geborgd in tekeningen en code.

Wat is het doel van het model?
In artikel 1 wordt het “swingtree project” beschreven. Het middel om dit soort projecten te voorkomen is het model. Dit is de “why” van het modelleren. Het model levert documentatie in de taal van de kenniswerker in het probleemdomein. Dit betekent dat het model in een taal is geschreven zonder technische oplossingen en begrijpbaar voor de kenniswerker en andere betrokkenen. Concreet, er moeten termen worden gebruikt van de “werkvloer”. Als meerdere termen voor hetzelfde onderwerp worden gebruikt, moet de best passende term worden gekozen.
Het primaire doel van het model is dus het beschrijven van de “why” en “what” van het probleemdomein. Door middel van het model wordt:

• Kennis over het probleemdomein geborgd
• Spreken toekomstige gebuikers en de ontwikkelaars dezelfde taal
• De oplossing in code is herkenbaar, ook in de toekomst

Een secundaire doelstelling is het hebben van een basis voor het software ontwikkelteam om de oplossing te realiseren van het probleemdomein. Deze basis moet in de code worden herkend zodat ontwikkelaars snel vanuit het probleemdomein, de technische oplossing eigen kunnen maken. Op deze manier wordt code herkenbaar en wordt alleen noodzakelijke code geschreven. Binnen DDD wordt de taal van de werkvloer “ubiquitous language” genoemd.

Hoe pakken we dat aan?
Zonder het gestructureerd aanpakken van de analyse om tot het model te komen, kan een applicatie ontstaan zoals hieronder weergegeven. Voor een klein probleemdomein hoeft dat geen probleem te zijn. Echter, het probleem domein zal altijd onderhevig zijn aan veranderingen en wellicht uitbreidingen. Het resultaat is een nog complexer plaatje. Binnen DDD worden dergelijke oplossingen “Big ball of mud” genoemd.

Bron: Patterns, Principles and Practices of Domain Driven Design by: Millet & Tune

Beter is om deelgebieden van het probleemdomein te beschrijven. Dit zijn de “subdomains” van het probleemdomein. Per subdomein worden vervolgens de modellen opgesteld. Dit betekent ook dat de oplossing (de architectuur) bestaat uit subdomeinen. Het realiseren van de oplossing gebeurt met focus en kan zelfs door verschillende teams worden uitgevoerd. De applicatie resulteert dan in een plaatje wat vergelijkbaar is met de onderstaande.

Bron: Patterns, Principles and Practices of Domain Driven Design by: Millet & Tune

In het volgende artikel wordt dieper ingegaan op de inhoud van een model. Hier komen de termen als “aggregate root”, “entity” en “value objects” aan de orde.

Auteur: Arjen Kraak, Bergler Competence Center © 2018

Geinteresseerd in dit onderwerp? Lees dan ook het eerste artikel: www.bergler.nl/ddd-in-gewoon-nederlands-artikel-1-introductie (level-100)

Persoonlijk zie ik de beweging naar een meer open source cultuur in software development als een positieve. Daarin sta ik zeker niet alleen en ik weet dat veel collega’s hier een zelfde positief gevoel bij krijgen. Maar elke beweging heeft zijn eigen uitdagingen, nu bezocht ik laatst bij de Microsoft TechSummit waar ik een sessie over Ethical Hacking van Milad Aslaner heb bijgewoond. Hierin kwam ter sprake dat hackers zich momenteel vooral focussen op hacken van supply chains.

Onder supply chain verstaan wij de hele aaneenschakeling van ketens om van begin tot eindproduct te komen. Dit kunnen dus allemaal verschillende grondstoffen/ halffabricaten zijn, of in het geval van softwareontwikkeling b.v. reeds bestaande libraries, open source projecten of commerciële producten.

Nu is het hacken van de supply chain een vrij breed begrip, maar het komt erop neer dat alle schakels om tot een eindproduct te komen, vatbaar zijn voor een hack. Dit is natuurlijk niets nieuws maar toch ligt de focus vaak op het beveiligen van een eindproduct en worden de tussenstappen nog wel eens over het hoofd gezien.

Zo valt bijvoorbeeld de stuxnet hack onder een supplychain hack, hierbij wordt middels het beïnvloeden van Siemens PLC’s (welke nucleair materiaal centrifugeren) een poging gedaan om het Iraanse nucleaire project negatief te beïnvloeden. Of denk bijvoorbeeld aan deze waarschuwing over Russische hackers die netwerk apparatuur aanvallen. Dit klinkt wellicht als James Bond scenario’s, maar dichter bij huis zijn er legio voorbeelden van supply chain hacks waar we als softwareontwikkelaars direct last van hebben. Denk hier bijvoorbeeld aan hacks in package managers of Container Base Images. Deze kunnen deel uitmaken van de supply chain voor je softwareproject.

Package managers
Hier komt opensource weer om de hoek kijken, veel van de opensource initiatieven worden aangeboden via 1 van de vele package managers. Zoals b.v. NuGet, maven, bower of npm.

En zo is er in 2017 bijvoorbeeld malware gevonden in een zeer populair npm opensource package.
Als Microsoft ontwikkelaar maak ik persoonlijk veel gebruik van de NuGet Package Manager. We moeten niet naïef zijn, ook NuGet packages kunnen schadelijke code bevatten.

Hoe kun je je wapenen tegen malware en toch gebruik maken van de goede dingen van open source?

Hier zijn gelukkig wel mogelijkheden voor beschikbaar. Vanuit NuGet is er een initiatief op de roadmap gezet om packages te ondertekenen. Dit om de integriteit en authenticiteit van een package te kunnen garanderen.

https://blog.nuget.org/20170914/NuGet-Package-Signing.html

Daarnaast zijn er meerdere 3rd party services beschikbaar die alle dependencies in de code controleren. Voorbeelden hiervan zijn bijvoorbeeld:

• snyk : https://snyk.io/
• whitesource : https://www.whitesourcesoftware.com/
• veracode : https://www.veracode.com/

Deze of soortgelijke tools kunnen worden opgenomen in de build pipeline. Dit om direct bij elke build feedback te kunnen geven of een dependency is geïntroduceerd met een bekende kwetsbaarheid.

Containers
Naast het gebruik van package managers zijn containers momenteel een hot topic. Ook hier hebben we een potentieel risico aangezien hier vaak gebruik wordt gemaakt van reeds beschikbare door een derde partij gemaakte base images.

Hier hebben Michael Cherny en Sagie Dulce in 2017 een interessant stuk over geschreven.

Buiten het feit dat je hier met infrastructurele oplossingen mitigerende maatregelen kunt nemen zijn hier ook 3rd party mogelijkheden op je te wapenen tegen potentiele hacks. Voorbeelden hiervan zijn bijvoorbeeld:

• Clair : (https://github.com/coreos/clair) Clair is een open source project wat gebruik maakt van statische analyse van kwetsbaarheden. Clair doet periodieke updates van een database met daarin de bekende kwetsbaarheden.
• AquaSec: (https://www.aquasec.com/) AquaSec is een commercieel product ontworpen met containers in gedachte. Security audit, container image verificatie, runtime beveiliging, geautomatiseerde policy learning en inbraakbeveiliging mogelijkheden zijn de belangrijkste features.
• Anchore Navigator: (https://anchore.io/) Commercieel product maar Anchore Navigator biedt wel een gratis service om public Docker images aan een Deep inspection te onderwerpen. Je kunt ook gebuik maken van hun reeds controleerde container repository.

Deze producten werken vaak in combinatie met een specifieke container registry waarin alleen gecontroleerde containers in terecht kunnen komen.

Azure Security Center
Naast het gebruik van tools specifiek voor Package management en Container controle op kwetsbaarheden, is het geen overbodige luxe om de inzet van Azure Security Center te overwegen.

Azure Security Center biedt mogelijkheden om on premise en in de cloud, op basis van grote hoeveelheden telemetrie, abnormale patronen te herkennen. Dit gaat middels Machine Learning algoritmes. Er zijn allerlei verschillende indicatoren welken potentieel schadelijk gedrag zouden kunnen aantonen. Zo wordt er bijvoorbeeld door geavanceerde malware, traditionele malware scanners omzeild door niet meer (of versleuteld) naar schijf te schijven. Azure Security Center gebruikt hier een geheugenanalyse voor om deze malware toch te kunnen herkennen. Daarnaast worden afwijkingen van normaal gedrag gedetecteerd. Als het aantal aanmeldingen of het tijdstip van de aanmeldingen of de locatie van waaruit de aanmeldingen zijn aangevraagd of andere aanmeldingsgerelateerde kenmerken aanzienlijk verschillen van wat normaal is, kan een waarschuwing worden gegenereerd.
Azure Security Center biedt een zeer uitgebreide set aan services welke op hun beurt weer zeer veel mitigerende maatregelen treffen tegen allerlei potentiële kwetsbaarheden.

Be aware!
Wees je er van bewust dat er in het hele ontwikkeltraject meerdere plekken zijn waar zich potentiële kwetsbaarheden bevinden. Het is goed om hier bewust mee om te gaan en indien noodzakelijk hier mitigerende maatregelen te treffen. De hier beschreven services kunnen hier een rol in spelen, want om maar eens een open deur in te gooien: “Voorkomen is beter dan genezen”.

Auteur: Patrick Bes, Bergler Competence Center © 2018

Als Lead Developer ben ik betrokken bij het opmaken van business cases, uitwerken van ideeën en het implementeren van softwareoplossingen. Een steeds vaker terugkomend thema is dat mijn relaties hun applicatie landschap willen moderniseren zonder opnieuw het wiel te willen uitvinden.