Strategic Design – Stabile Software durch gute Beziehungen (Domain Driven Design, Teil 4)

In den letzten Artikeln wurde festgestellt, wie wichtig ein Domänenmodell und eine domänenbezogene Teamsprache für die Erstellung langlebiger und stabiler Software sind. Wie schafft man es aber, die Entwicklung so zu organisieren, dass große und komplexe Projekte nicht in kleinteiligen Modellen und einer unübersichtlichen Sprache versanden?WeiterlesenWeiterlesen

Die ubiquitäre Sprache – Der rote Faden im Softwaresystem (Domain Driven Design, Teil 3)

„To create a supple, knowledge-rich design calls for a versatile, shared team language“ schreibt Eric Evans. Um Software gut zu designen, braucht das Team eine gemeinsame sprachliche Basis. Selbstverständlich nimmt kein Entwickler an, er würde den Kunden oder seinen Stellvertreter im Projekt nicht verstehen oder sich nicht verständlich ausdrücken. Trotzdem kommt es in Software-Projekten immer wieder zu Fehlinterpretationen und irreführenden Bezeichnungen. Spätestens nach einigen Jahren im Gebrauch weiß keiner mehr, was mit einem bestimmten Methodennamen genau gemeint war, es kommt zu unsachgemäßer Wiederverwendung und Erweiterungen – die Software erodiert.WeiterlesenWeiterlesen

Das Domänenmodell – Dreh- und Angelpunkt der Entwicklung (Domain Driven Design, Teil 2)

Die Erstellung eines lebendigen, mitwachsenden Domänenmodells steht im Zentrum des Domain Driven Design. Bedeutet das, neben der Entwicklung auch noch parallel ein Modell pflegen zu müssen? Als zusätzliche Dokumentation sozusagen? Und wie soll dieses Modell überhaupt aussehen? Brauche ich nur ein Domänenmodell, um von den Vorteilen des Domain Driven Design zu profitieren? Und – was ist überhaupt die „Domäne“?WeiterlesenWeiterlesen