Software Architectuur

Waarom Grote Software Projecten Falen

Een van de grootste misverstanden in software engineering is dat falen vaak te wijten is aan de verkeerde technologie, een trage database of een verouderd framework. In werkelijkheid stagneren grootschalige IT-projecten in de enterprise-sector vrijwel altijd door een gebrek aan communicatie en een fundamenteel onbegrip van het bedrijfsdomein (de business). Ontwikkelaars praten in termen van tabellen, foreign keys, classes en API’s, terwijl de domeinexperts (bijv. logistiek planners, financiële auditors of HR-managers) spreken in bedrijfsconcepten en processen. Deze vertaalslag leidt onherroepelijk tot ‘spaghetti-code’ waarbij bedrijfsregels verspreid en verborgen zitten in UI-controllers en database-scripts. Domain-Driven Design (DDD), geïntroduceerd door Eric Evans, biedt de methodiek om deze kloof te dichten.

DDD is geen technologisch framework of een programmeertaal, maar een filosofie en een set van ontwerppatronen die de focus leggen op de kern van de business. Het stelt dat de structuur en taal van de software exact overeen moeten komen met het bedrijfsdomein.

De Ubiquitous Language (De Universele Taal)

Het fundament van DDD is de ‘Ubiquitous Language’. Dit is een gedeelde, strikt gedefinieerde taal die zowel door de domeinexperts als door de softwareontwikkelaars wordt gesproken, én die letterlijk terug te vinden is in de broncode. Als de logistieke afdeling spreekt over een ‘Vrachtbrief’ (Waybill) die wordt ‘Gefiatteerd’ (Approved), dan mogen de ontwikkelaars dit in de database of code niet benoemen als DocumentStatus = 1 of DeliveryNote.SetTrue(). Er moet een class Waybill zijn met een methode Approve(). Door deze universele taal af te dwingen, fungeert de code als de ultieme, levende documentatie van het bedrijfsproces.

Bounded Contexts en de Ontkoppeling van Modellen

In grote organisaties betekent hetzelfde woord vaak iets compleet anders, afhankelijk van de afdeling. Een ‘Klant’ in het CRM-systeem (met een focus op leads, marketingvoorkeuren en acquisitie) heeft volstrekt andere attributen en regels dan een ‘Klant’ in het facturatiesysteem (waar het draait om KVK-nummers, betalingstermijnen en kredietlimieten). Proberen om één gigantische, universele ‘Klant’-class te bouwen in een centrale database, leidt tot onbeheersbare complexiteit.

DDD lost dit op via ‘Bounded Contexts’. Het verdeelt het grote bedrijfssysteem in afgebakende grenzen (contexts). Binnen de facturatie-context bestaat er een specifiek BillingCustomer model; binnen het CRM is er een LeadCustomer model. Deze modellen zijn strikt gescheiden. Dit concept vormt de absolute theoretische basis voor een succesvolle microservices-architectuur. Zonder duidelijke Bounded Contexts, eindigt u met een ‘Distributed Monolith’, waarbij de nadelen van microservices worden gecombineerd met de nadelen van een monolithisch systeem.

Tactische Patronen: Entities, Value Objects en Aggregates

Op codeniveau biedt DDD tactische patronen om de complexiteit te structureren:

• Entities: Objecten met een eigen identiteit die door de tijd heen verandert (bijv. een Bestelling met een uniek ID).
• Value Objects: Onveranderlijke (immutable) objecten zonder identiteit, gedefinieerd door hun attributen (bijv. een Adres of een GeldBedrag). Ze bevatten eigen validatie-logica (een bedrag kan niet negatief zijn) waardoor de Entity-classes schoon blijven.
• Aggregates: Clusters van gerelateerde Entities en Value Objects die samen één transactionele eenheid vormen. De wijzigingen binnen een Aggregate worden gecoördineerd door de ‘Aggregate Root’. Dit garandeert dat alle bedrijfsregels (invariants) binnen de transactie te allen tijde consistent blijven.

Domain-Driven Design vergt een forse intellectuele investering vooraf en vereist actieve deelname van niet-technische experts. Voor simpele CRUD-applicaties is het overkill, maar voor de kernsystemen van grote ondernemingen is het de enige manier om software beheersbaar te houden over een decennium. Lees meer over architectuurprincipes op AG Connect.

Geavanceerde TypeScript Patronen: Van Generics tot Utility Types in Grote Codebases

Inhoudsopgave