Strategiczne Domain-Driven Design

Strategiczne Domain-Driven Design może pomagać porządkować złożoność systemów i może kierować rozwojem oprogramowania zgodnie z potrzebami biznesu. Klarowny podział domeny może ułatwiać współpracę zespołów i może zmniejszać ryzyko błędnych integracji.

Model domeny może:

• odzwierciedlać język i reguły biznesowe
• upraszczać decyzje projektowe poprzez wspólne pojęcia
• ograniczać sprzężenia przez precyzyjne granice

Wspólny język (Ubiquitous Language) może:

• redukować nieporozumienia między biznesem a IT
• przyspieszać analizę wymagań dzięki jednoznacznym definicjom

Ograniczony kontekst (Bounded Context) może:

• wyznaczać zakres odpowiedzialności dla modelu
• umożliwiać niezależny rozwój i wdrażanie

Context Map może:

• ujawniać zależności pomiędzy kontekstami
• wskazywać wzorce współpracy (np. partnerska, klient–dostawca)
• identyfikować miejsca ryzyka integracyjnego

Antikorruption Layer może:

• chronić model przed erozją na styku z systemami zewnętrznymi
• tłumaczyć pojęcia między różnymi modelami

• Wydzielenie kontekstów rdzeniowych może koncentrować inwestycje na tym, co tworzy przewagę.
• Konteksty wspierające i ogólne mogą być standaryzowane lub delegowane do gotowych rozwiązań.
• Dobór granic zespołów do granic kontekstów może zmniejszać koszty koordynacji.

Zespoły produktowe mogą:

• współdzielić język z interesariuszami
• utrzymywać autonomię dzięki niezależnym backlogom i cyklom

Architektura może:

• odzwierciedlać granice kontekstów w modułach i kontraktach
• ułatwiać skalowanie przez niezależne komponenty i jasne API

• Zbyt drobny podział kontekstów może zwiększać koszt integracji i utrzymania.
• Brak jednolitego języka w kontekście może prowadzić do rozjechania modelu i długu.
• Niedoszacowanie zależności między kontekstami może utrudniać dostarczanie i synchronizację zmian