Im Leben eines Entwicklers gibt es immer wieder „Aha“- oder sog. „Breakthrough“-Momente, in denen man entweder etwas entdeckt, dass die eigenen Fähigkeiten beträchtlich erweitert oder lange bestehende Probleme löst.
Hier geht es um ein solches, (noch) kaum bekanntes und bisher selten angewendetes Prinzip für das Design von objektorientierter Software. Meines Erachtens ist es sehr einfach zu verstehen und auch sehr einfach anwendbar. Aber noch größer sind die Vorteile die es bietet.
Jemandem DDD (Domain-driven Design) zu erklären, scheint nicht immer ganz einfach zu sein. Entweder ist es zu technologielastig oder aber zu abstrakt, je nachdem mit welcher Zielgruppe man es zu tun hat.
Ist DDD …
– ein Pattern?
– eine Philosophie?
– eine Architektur?
– ein Entwicklungsansatz?
– ein Prinzip?
– eine Modeerscheinung?
– Nichts (oder alles) davon.
Abgesehen von der trivialsten Software bewegen sich die meisten Anwendungen in einem mehr oder weniger komplexen Problemumfeld (Domäne). Bevor man nicht weiß, welche Bereiche mit welchen Verantwortlichkeiten existieren, in welchen Umgebungen man sich bewegt und welches Problem sie eigentlich lösen sollen, macht es keinen Sinn über Architekturen, Datenformate, Datenstrukturen, Frameworks oder Lösungsansätze nachzudenken.