DDD nie jest metodyką tworzenia kodu, a definiowaniem komunikacji (połączeń) pomiędzy obiektami.
DDD mówi o tym w jaki sposób rozmawiać z klientem, abyśmy mogli zrozumieć domenę problemu - czyli sedno tego, co następnie opakujemy w kod.
Eric stworzył wiele koncepcji. Niektóre z nich:
- Model-Driven design
- Bounded Contex
- Core Domain
- Generic Subdomains
- Context Map
Szczególnie ciekawa koncepcja to Bounded Context - wyrażenie to przetłumaczył bym jako ograniczony czy też zawężony kontekst.
W większości projektów, tworzony jest jeden model, który reprezentuje całą aplikację. Bounded Context ma za zadanie podzielić problem na mniejsze, czyli stworzyć wiele małych modeli. Każdy z małych modeli dotyczy jednego specyficznego obszaru i definiuje operacje tylko z nim związane. Jako deweloperom daje nam to wskazówki, co w danym modelu ma zostać zaimplementowane, a co powinniśmy przenieść do innego/nowego modelu.
Standardowo tworzoną aplikację można przedstawić w następujący sposób:
Jeżeli chcielibyśmy tutaj wykorzystać metodykę Bounded Context, podział mógłby wyglądać następująco:
Encja Customer występuje w wielu kontekstach. Nie jest więc twardo powiedziane, że dana encja ma się w całym modelu pojawić tylko raz. Oczywiście nie znaczy to, że w każdym miejscu musi posiadać ten sam zbiór pól i operacji. W kolejnym poście pojawi się przykład obrazujący tworzenie Bounded Context.
Brak komentarzy:
Prześlij komentarz