Wśród programistów DDD jest głównie znane ze wzorców taktycznych (niestety…). Moim zdaniem ten stan rzeczy wynika z faktu, że te wzorce są bliższe implementacji. Co za tym idzie, nie trzeba gadać z ludźmi, aby “DDD” robić (chociaż jak pokazuje Domain Drivers można robić też tzw. DDD Lean nie mając dostępu do “byznesu” - zainteresowanych zachęcam do udziału w szkoleniu). Dobra, ale do rzeczy. W arsenale wzorców taktycznych znajduje się coś takiego jak Polityka. Czym ten element tak naprawdę jest?

To nic innego jak wariant znanego wzorca projektowego - Strategia - opisanego w słynnej książce Gangs Of Four. W skrócie pozwala nam on na wymianę rozwiązań/algorytmów zachowując stabilny interfejs.

Jak to wpasowuje się w pryncypia DDD? Dzięki polityce możemy oddzielić to co jest stabilne od tego co takie nie jest. W odniesieniu do reguł biznesowych. Zachowania modelu domenowego mogą być dostrajane dzięki dostarczaniu zmiennych reguł poprzez stabilny interfejs.

Przykład? Wróćmy do często omawianej domeny na tym blogu dotyczącej obsługi parkingu. Załóżmy, że mamy tam byt ParkingSpot odzworowujący miejsce postojowe. Stabilną regułą, która nigdy nie może zostać złamana, jest fakt, że dane miejsce postojowe ma fizyczny limit przestrzeni do zagospodarowania. Czyli w skórcie, nie może na nim być więcej “obiektów” (mogą to być pojazdy albo też kartony?) niż jest to możliwe. Nazwałbym taką regułę - regułą zdrowego rozsądku. Natomiast geneza stwierdzeń takich jak:

  • miejsce postojowe jest wyłączone z możliwości parkowania w co drugi czwartek po godzinie 17
  • w piątki i w co drugi wtorek na miejscach postojowych mogą stać tylko duże pojazdy, w inne dni będą one dostępne również dla mniejszych pojazdów

…dotyczy specyficznych przypadków działania danego biznesu. Takie reguły są niestabilne i mogą się często zmieniać, bo np. biznes chce eksperymentować albo zmienia się zarząd, który chce wprowadzić “nowy porządek” pokazując kto tutaj rządzi.

Właśnie tym dla mnie jest element kontrukcyjny o wdzięcznej nazwie polityka. To on pozwala nam zapewnić spełnienie reguły Open/Closed Principle, co w sumie nie jest kluczowe. Ważniejsze jest, że po prostu pomaga nam zmniejszyć naszą frustrację wylewaną na kod oraz szybciej dostarczać wartość biznesową.