Tell, don’t ask
Tell, don’t ask, lub, jak kto woli w oryginale:
Procedural code gets information then makes decisions. Object-oriented code tells objects to do things
— Alec Sharp
to stara zasada projektowania obiektowego mająca swoje odzwierciedlenie także na poziomie architektury. I, o ile na poziomie programowania nikt właściwie jej nie kwestionuje, o tyle na wyższych poziomach abstrakcji propozycje jej wprowadzenia budzą znaczący sprzeciw. Dlaczego? Tego nie wiem.
Głównym powodem stosowania wspomnianej reguły dla kodu obiektowego jest chęć zachowania niskiego poziomu powiązania. Nie powinniśmy uzależniać swojego kodu od wewnętrznej implementacji obiektu, z którego korzystamy. Co więcej, ten drugi obiekt niechętnie eksponuje nam swoje wnętrze za pomocą odpytań, ponieważ czyniąc to sabotuje wszelkie późniejsze modyfikację, gdyż udostępnione szczegóły stają się natychmiast częścią publicznego kontraktu jego API.
Domain-Driven Design sprawdza się najlepiej w przypadku implementacji skomplikowanej logiki, która charakteryzuje się dużą podatnością na zmiany (Udi Dahan w MSDN Magazine). Stosowanie DDD, aby umożliwić szybkie zmiany, a jednocześnie ignorowanie zasady tell, don’t ask (prowadzące do narastania utrudniających wszelkie modyfikację powiązań) wydaje się kompletnie pozbawione sensu! A jednak, wielokrotnie słyszymy, że DDD jest w porządku, ale promujący podejście tell, don’t ask wzorzec CQRS to przerost formy nad treścią.
Powtórzę jeszcze raz to, co świetnie opisał Greg: CQRS jest zupełnie niezależny od decyzji architektonicznych. CQRS nie wymaga Event Sourcing-u (choć dobrze z nim współgra). CQRS nie wymaga nawet osobnych magazynów danych (choć traci wtedy wiele ze swej mocy). CQRS nie kosztuje praktycznie nic, jeśli już decydujemy się na DDD. Naprawdę nie ma się czego bać!
