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

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
TechEd: The Zen of Architecture
Druga notka na temat pojedynczej sesji TechEd i znów dotyczy prezentacji Juval-a Lowy. Tym razem na warsztat postanowiłem wziąć prezentację o nieco intrygującym tytule "The Zen of Architecture". W moim przekonaniu Lowy był gwiazdą tegorocznej edycji TechEd, przynajmniej jeśli chodzi o tematy mnie interesujące, czyli architektura, SOA i okolice.

Wprowadzenie


Na początek pan Lowy przedstawił się nam z jak najlepszej strony: że jest architektem, że jest MS Regional Director, że napisał dwie książki i takie tam. Generalnie - robiące wrażenie i mało interesujące. Następnie przeszedł do konkretów. Lowy opracował proces projektowania architektury aplikacji .NET, który pozwala w dużym stopniu zautomatyzować i ustrukturyzować pracę architekta. Nazwał ten proces Metodą (The Method). Więcej informacji na temat Metody można znaleźć na stronie Juval-a.

Najważniesze (według mnie) cechy metody to ściśle określony czas trwania procesu projektowania architektry oraz niestandardowy sposób dokumentowania rezultatów tegoż procesu. Lowy twierdzi, że 2-3 dni to wystarczająca ilość czasu, aby dobrze zaprojektować architekturę systemu. Limit 3 dni ma sens, ponieważ zapobiega niepotrzebnemu dopracowywaniu projektu (skutkującemu często przekombinowaniem - overarchitecture). Efektem tych kilku dni pracy ma być kilkadziesiąt (40-60) prostych diagramów składających się jedynie z prostokątów i linii. Diagramy te nie mają nic wspólnego z UML-em. Lowy przekonuje, że UML jest zbytnio zorientowany na obiekty, aby być użytecznym na poziomie architektury (gdzie generalnie operujemy usługami i komponentami).

Moje osobiste zdanie jest takie, że sposób rysowania wykorzystywany w Metodzie może być niewystarczający do przekazania przeciętnemu odbiorcy najważniejszych informacji dotyczących architektury systemu. Diagramy, które prezentował Lowy pokazywały bardzo dobrze archietkturę systemu "metamerycznego" - składającego się z wielu powtarzalnych fragmentów, z których każdy ma identyczną strukturę.

Systemy, których architekture projektowałem lub opiniowałem nie wyglądały praktycznie nigdy w ten sposób. Kluczową informacją, jaką trzeba było w ich przypadku przekazać były relacje między elementami systemu, np.
  • komunikacja synchroniczna (wraz z określeniem kierunku)
  • komunikacja asynchroniczna
  • replikacja lub publikowanie danych
  • realizacja pewnej bardziej asbtrakcyjnej funkcjonalności
Relacje te bardzo dobrze oddaje diagram komponentowy UML-a: mamy do dyspozycji wiele różnych rodzajów strzałek, którymi możemy rozróżnić poszczególne typy relacji. Tak naprawdę diagramy Lowy-ego można określić jako uproszczenie UML-owej notacji komponentowej. Moim skromnym zdaniem lepiej trzymać się jakichś standardów, niż wymyślać "nowe".

Dekompozycja


Lowy jest przeciwnikiem dekompozycji opartej o diagramy przepływu (flow-chart decomposition), nazywanej przez niego funkcjonalną. Jego zdaniem oznacza ona, że projekt architektury nie dodaje żadnej wartości w stosunku do diagramu sekwencji w przypadkach użycia. Trudno się z tym nie zgodzić. Z drugiej jednak strony - na czym w takim razie oprzeć dekompozycję? Lowy proponuje zmienność (volatility). Idea polega na identyfikacji obszarów zmienności i enkapsulacji ich w usługi. Idea zacna, tylko niestety nijak nie mogę jej przetłumaczyć na implementację. Podpowiedź z prezentacji: "zaimplementuj zachowanie jako interakcję między zmiennymi usłgami" niestety to również nic mi nie mówi.

Osobiście jestem ogromnym zwolennikiem enkapsulacji opartej o stopień zmienności. Złapałem tego bakcyla przy okazji czytania o architekturze cebulowej. Uważam jednak, że sama analiza zmienności jest niewystarczająca. Wykorzystuję ją jako uzupełnienie do analizy opartej o odpowiedzialności. Dekomponując system staram się zidentyfikować atomowe odpowiedzialności, a następnie pogrupować je w komponenty według obiektów biznesowych, których odpowiedzialności dotyczą. W ten sposób staram się minimalizować wymagną dla działania komponentów komunikację. Idealnie każdy komponent do działania potrzebuje tylko swoich lokalnych danych. Niestety taka idealna sytuacja jest nierealna. W praktyce staram się zminimalizować komunikację "on-line" (związaną z przetwarzaniem konkretnych żądań) kosztem replikowania informacji między komponentami za pomocą publikowania/subskrypcji (komunikacja tylko kiedy dane się zmienią, a nie per żądanie).

Warstwy

Cebula ma warstwy, tort ma warstwy, Ogry mają warstwy. Jeśli wolimy, żeby nasza aplikacja kojarzyła się bardziej z pysznym tortem niż ze śmierdzącym ogrem, lepiej, żeby miała sensowny podział na warstwy.

Warstwy według Metody Lowy-ego są cztery:
  • Kliencka (interfejs użytkownika, klient usługi web itp)
  • Logiki biznesowej
  • Dostępu do zasobów
  • Zasobów
Poza tymi czterema poziomymi warstwami jest jeszcze warstwa infrastruktury, która jest dostępna z poziomu każdej z wymienionych "normalnych" warstw. Warstwa logiki biznesowej składa się z silników (engine) oraz menedżerów (manager). Menedżer reprezentuje grupę powiązanych ze sobą przypadków użycia i jest odpowiedzialny za sekwencję czynności realizowanych w ramach tych przypadków. W celu wykonania poszczególnych czynności menedżer wykorzystuje silniki. Silniki mogą być współdzielone między menedżerami. Wszelka komunikacja pomiędzy warstwami odbywa się za pośrednictwem obiektów DTO. Lowy zaleca, aby fizycznie komunikację tę zrealizować za pośrednictwem WCF-u.

Jedno, co mnie zastanawia w tym podejściu to fakt, że kompletnie pomijamy temat Domain Driven Design. Słuchając tej prezentacji czekałem z niecierpliwością, aż Lowy zacznie mówić o stosunku Metody do modelowania domeny. Nie doczekałem się. Tak, jak ja rozumiem Metodę, silniki realizują dostęp do danych za pośrednictwem warstwy dostępu do zasobów. Silniki reprezentują czynności. Nie ma więc miejsca na obiekty reprezentujące byty domeny problemu. Rozumiem, że nie wszystkie systemy muszą być budowane zgodnie z DDD. Rozumiem, że DDD nie jest silver-bullet. Pojąć jednak nie mogę, jak Metoda, która ma być standardowym podejściem do architektury systemów może w kompletnie ignorować kwestię modelowania domeny.

Podsumowanie


Mimo szczerych chęci nie udało mi się odnieść do całości prezentacji Lowe-go. Tak naprawdę to nie doszedłem nawet do połowy, a notka juz zrobiła się za długa. Pewnie za dużo pisałem o sobie;-). Cóż, mam nadzieję że niedługo uda mi się znów znaleźć trochę czasu i powstanie druga notka, kontynuująca temat.

Juval Lowe imponuje mi metodycznym podejściem do architektury. Chciałbym kiedyś, aby projektowanie systemów było dla mnie tak naturalne i tak usystematyzowane, jak to prezentuje Lowe. Z drugiej stronych bardzo nie chciałbym popaść w rutynę, aby każdy mój system wyglądał identycznie na diagramie warstw. Po co wtedy byłby architekt?

Lowe jest bardzo kontrowersyjny w swoich poglądach (każda klasa jako usługa WCF). Dzięki temu jest postacią barwną i potrafi przyciągnąć na tyle, aby sprzedać swoje koncepcje. Niektóre z nich są naprawdę dobre. Inne mogą się nie podobać, ale nie pozwalają człowiekowi być obojętnym. Pobudzają do twórczego myślenia. Dlatego właśnie uważam, że Lowe był gwiazdą ścieżki architektonicznej TechEd US 2009.

Opublikowane 13 czerwca 2009 17:05 przez simon

Filed under: ,

Komentarze:

# Simon says... : TechEd: The Zen of Architecture @ 13 czerwca 2009 20:25

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

dotnetomaniak.pl

Komentarze anonimowe wyłączone