(En de “Hexagonal” architectuur dus ook.)

Nadat Uncle Bob (Robert Martin) jaren geleden zijn “Clean Architecture” in een vaag artikel op zijn blog beschreef, heb ik deze architectuur in verschillende Java backend projecten met wisselend succes toegepast. In eerste instantie door mijn onbegrip over zijn suggesties 🤷‍♂️, maar later ook door onbegrip over wat het werkelijk brengt. 🤦‍♂️

In de wereldwijde Flutter gemeenschap blijkt Clean Architecture inmiddels ook een enorme opmars the hebben gemaakt. Maar ook daar lijkt het onbegrip hoogtij te vieren, waardoor zelfs simpele apps trots worden gebouwd als enorme gelaagde gedrochten. 🦄

Fundamenteel is Clean Architecture een poging om vanwege “Separation of Concerns” het domein van de applicatie los te weken van de opslag en de toepassing in een IT omgeving (=de UX of een API). Hiervoor wordt de code in lagen verdeeld, met een strikte oriëntatie van alle afhankelijkheden richting de domein code.

En die strikte opdeling is waar het vaak mis gaat:

➡️ Is die volledige Separation of Concerns wel altijd zo zinvol als de applicatie niet zo groot is, of maar door een enkele ontwikkelaar wordt beheerd?

➡️ Wat nou als het “domein” in de UX of juist in de database is gestopt, en er dus nauwelijks domein over blijft?

Door in die gevallen toch vast te houden aan de voorgeschreven rigide opdeling, is het resultaat een wirwar van interface, classes, en conversies die alleen nog aan de onderhoudskosten en hoeveelheid bugs bijdragen.💩

Clean Architecture is volgens mij nog steeds een goed idee 🌈, maar het is zeker niet de oplossing voor elke situatie.