Czytam sobie Implementing DDD Vaughna Vernona. Autor stawia tam podział na strategic DDD (Ubiquitous Language, Core/ Supporting/ Generic Domain, Bounded Context, Context Map) i tactical DDD (Entity, Value Object, Aggregate, Domain Event, Repository, itd). Strategic DDD jest tą ważniejszą częścią DDD, a tactical DDD (bez strategic DDD) określa jako DDD-Lite, które samo w sobie daje niewiele zysku.
Strategic DDD w dużej mierze opiera się o Ubiquitous Language. To UL steruje podziałem na BC oraz komunikacją w zespole, zarówno między samymi programistami, jak i między programistami, a np ekspertami domenowymi, a nawet słownictwem używanym w interfejsie użytkownika czy API serwisów. Szerokie używanie UL wydaje mi się jednak nierealistyczne, bo trzeba nauczyć wszystkich zaangażowanych w projekt (programistów, menedżerów, ekspertów dziedzinowych, wsparcie produkcji, testerów, itd) by używali innego słownictwa (Ubiquitous Language) w zależności od omawianej części systemu (Bounded Context). Stąd w praktyce podział na Bounded Contexts i powiązane z nimi wyspecjalizowane Ubiquitous Languages będzie prawdopodobnie widoczny tylko w kodzie i dokumentacji stworzonej przez programistów, a nie w dokumentacji i poleceniach od zarządu czy ekspertów domenowych.
Jak zmieniła się wasza komunikacja z resztą zespołu (czyli programistami oraz innymi zaangażowanymi w projekt jak zarządem, ekspertami domenowi, wsparciem, testerami, itd) po wprowadzeniu DDD? Używacie wyspecjalizowanych Ubiquitous Languages w zależności od Bounded Contextów?