Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
DDD i breakthrough refactoring
Są takie momenty w życiu modelu domeny, kiedy niewinna, z pozoru, refaktoryzacja powoduje przełomowe zmiany w jego strukturze i zachowaniu. Jest to zjawisko, które (wg Erica Evansa) jest ostatecznym celem procesu knowledge crunching będącego istotą DDD.

Jakiś tydzień temu byłem uczestnikiem właśnie takiego zjawiska. Moduł Zabezpieczeń, nad którym od jakiegoś czasu się pracowaliśmy zajmował się przetwarzaniem zabezpieczeń dla różnych obiektów biznesowych: ofert, transakcji, grafików. Nie miało to jednak żadnego odzwierciedlenia w jego strukturze, no może poza obiektem Zabezpieczenia, który był połączony ze wspomnianymi za pomocą relacji wiele-do-jeden. Obiekt ten nie miał jednak żadnego zachowania.

Wszelkie procesy biznesowe zrealizowane były jako metody warstwy usługowej wykonujące "magiczne" operacje na kolekcjach zabezpieczeń oraz jednocześnie wysyłające odpowiednie komunikaty do zewnętrznego systemu transakcyjnego. Inne metody przetwarzały komunikaty zwrotne aktualizując stan listy obiektów reprezentujących zabezpieczenia.

Impulsem dla zmian było moje pragnienie przeniesienia wspomnianej logiki na poziom modelu. Przełomem zaś okazało się być zamknięcie grupy Zabezpieczeń związanych z jednym obiektem w obiekt KolekcjaZabezpieczeń. Obiekt ten, mimo iż nie jest encją, natycmiast stał się centralny dla całego modułu. Okazało się, że za pomocą jednynie 3 operacji:
  • Take - zlecenia zmniejszenia zabezpieczeń
  • Modify - zlecenia modyfikacji zabezpieczeń
  • ApplyChanges - uwzględnienia odpowiedzi systemu zewnętrznego
udało się wyrazić najważniejsze procesy dziejące się w module. Wszystkie wieloekranowe metody warstwy usługowej udało się zastąpić wywołaniami Taka i Modify drastycznie zmniejszając ilość kodu. Wszystkie metody przetwarzania odpowiedzi udało się zastąpić poejedynczym ApplyChanges. Wypychanie danych do systemu zewnętrznego  zostało zlokalizowane w jednym miejscu -- klasie obsługi zdarzenia domenoego (dzięki, Udi!) "zaktualizowano kolekcję zabezpieczeń" zgłaszanego po każdej modyfikacji KolekcjiZabezpieczeń.

Czyż to nie piękne?

PS. Wniosek na przyszłość: nigdy, przenigdy, nie dopuszczać do tego, aby obiekt modelu domeny posiadał publiczne property typu List. Nie i koniec!

Opublikowane 15 listopada 2009 17:01 przez simon

Komentarze:

# DDD i breakthrough refactoring @ 15 listopada 2009 17:59

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

dotnetomaniak.pl

Komentarze anonimowe wyłączone