Tag domain-driven design
Technieken vs trucjes
Een goede programmeur is een luie programmeur – dat is een bekende wijsheid in softwareontwikkelland. Want: een luie programmeur automatiseert oninteressante, repetitieve taken, en creëert op die manier de ruimte om zich bezig te houden met interessante, afwisselende taken. – Althans, dat is één opvatting van wat het betekent om een luie programmeur te zijn. Maar er zijn nog veel meer manieren om lui te zijn. Vandaag wil ik het hebben over zo’n andere manier. Vandaag wil ik het hebben over de wens, behoefte of neiging om een techniek te reduceren tot een trucje.
Pseudofilosofische onderzoekingen (I & II)
Ik ga vandaag geen blog schrijven. Ik zal genoegen nemen met enkele aantekeningen die ik maanden geleden op papier zette, geïnspireerd door Marcus Aurelius en door Ludwig Wittgenstein. Het spreekt voor zich dat mijn overpeinzingen beduidend minder diepzinnig zijn dan die van beide grootheden.
De programmeur, de filosoof
We kunnen als softwareontwikkelaars veel leren van Socrates' filosofische houding. “Ik weet dat ik niets weet” betekent: ik neem niets aan, ik luister alleen goed naar wat de ander zegt en probeer diens standpunt zo helder mogelijk te krijgen. Ik hoor aan, parafraseer en controleer of die parafrase klopt. Voorzichtig trek ik conclusies - niet om de ander onderuit te halen, maar om te kijken of ik op de juiste weg ben, de ander begrijp. En ook: of het verhaal van de ander klopt - wat dat dan ook moge betekenen.
Eerlijke domeinmodellen
Options en Eithers vormen nog maar de eerste aanzetten voor het idee van eerlijke functies. Het zijn constructen die, op het oog althans, redelijk beperkt blijven tot het technische domein. Maar het idee van eerlijke functies past ook uitstekend bij de praktijk van het modelleren van een domein, zoals gebruikelijk in Domain-Driven Design. Dat is een les die ik leerde van Scott Wlaschin op DevTernity.
Zes dingen die ik leerde op Techorama
Een tijd geleden bezocht ik softwareconferentie Techorama in Utrecht. Ik hoorde een boel nieuwe ideeën, werd gesterkt in enkele van mijn al bestaande overtuigingen, en uitgedaagd sommige ingesleten gewoonten te herzien. Uit mijn stapel aantekeningen destilleer ik zes inzichten die ik alleen al de eerste dag opdeed.
Horizontale en verticale architectuur
Als we onze applicatie verticaal op zouden hakken, dan zouden we af kunnen komen van onze ongemakkelijke naamgevingsconventies. Elke slice zou zijn eigen project krijgen, en elk project zijn eigen model. Of het nu over items in isolatie gaat, of items in een toets, of items in een itembank - we zouden in de code altijd over Item kunnen spreken - net als de gebruiker.
Zelfs de testpiramide is niet meer heilig!
Ik ben altijd in de veronderstelling geweest dat mijn geautomatiseerde tests een piramidevormige verhouding tot elkaar zouden moeten hebben: aan de basis enorm veel unittests, in het midden een goede hoeveelheid integratietests, en aan de top een bescheiden aantal end to end (E2E) tests. Totdat ik Learning Domain-Driven Design van Vlad Khononov las. (Een aanrader, overigens!)
De ontdekking van strategische subdomeinen
Ik schreef één keer eerder over Domain-Driven Design - en in die blog gaf ik onmiddellijk toe niks van het onderwerp te weten. Precies daarom nam ik me voor om Learning Domain-Driven Design van Vlad Khononov op te pakken. En met succes, want al meteen in het eerste hoofdstuk leerde ik iets nieuws: het bestaan van strategische subdomeinen.
Domain-Driven Design en Ludwig Wittgenstein
Vaak gebruiken verschillende delen van de business dezelfde woorden op verschillende manieren, of gebruiken ze verschillende woorden voor hetzelfde concept. Dat is een frustrerende situatie voor een softwareontwikkelaar, maar een feest voor een taalfilosoof.