Dzisiaj pierwszy post z nowej serii. Jest to odcinek pilotażowy tasiemca, który z założenia ma być od teraz głównym wątkiem tego blogaska. Zgodnie z tytułem blogaska - będzie holistycznie (hasło to przestanie być pretensjonalnym buzzwordem).
Przygotowuję się powoli do rozpoczęcia nowego projektu. Jest to któryś już z kolei projekt, w którym będę uczestniczył - tym razem jako team leader. Jak zwykle obiecuję sobie, że tym razem będzie bardziej profesjonalnie i że tym razem będzie to miało przysłowiowe ręce i nogi (oraz nie 3 ręce i nie 8 nóg).
W ciągu pięciu lat pracy dobrze nauczyłem się jak NIE podchodzić do projektów - jest to wiedza praktyczna. Marność nad marnościami. Jednak tym razem zamierzam zastosować nabytą w ciągu ostatniego roku wiedzę teoretyczną... Unified Process (krótki wstęp) będzie procesem wytwórczym według którego będę chciał postępować. Główne fazy UP to analiza i projekt. Aby im sprostać posłużę się wytycznymi Domain Driven Design (dotychczasowe wypociny).
Zatem zamierzam przeprowadzić studium przypadku. Od czasu do czasu będę relacjonował jak sprawdza się UP i DDD w praktyce. Oczywiście treść będzie obdarta z kontekstu biznesowego:) Przykłady z wiadomych względów zostaną podniesione na nieco wyższy poziom abstrakcji.
Dodatkowo całość będzie zanurzona w kontekście technologicznym. Sam jestem ciekaw jak frameworki udźwigną ambitne założenia DDD:) Nie będę zanudzał tutorialami o popularnych frameworkach - jest tego pod dostatkiem i każdy na pewno znajduje dla siebie materiały odpowiadające osobistym preferencjom kognitywnym.
Relacja pomiędzy UP a DDD polega na tym, że UP jako proces wytwórczy prowadzi przez kolejny fazy (analiza biznesowa, systemowa, architektura, projekt implementacja, testy, wdrożenie); fazy dodatkowo zapętlone w iteracje. Natomiast DDD jest sposobem myślenia o fazach analizy (OOA) i projektowania (OOD) jako całości.
//===================
Nie pozostaje mi nic innego jak zaprosić do śledzenia postów otagowanych "UP-DDD in Action"
2 komentarze:
Podczytuję blogaska już od jakiegoś czasu więc pora na mój pierwszy komentarz.
Cieszę się, że rozpocząłeś tego tasiemca. Jak wiesz ja również uczestniczę w projekcie opartym na UP i DDD. Z miłą chęcią powymieniam spostrzeżenia. A nóż wyjdzie z tego coś "stymulującego" ;)
Zastanawia mnie tylko jedno. Jak długo będziesz musiał czekać na decyzję kogoś "z góry", że bezapelacyjnie konieczna jest operacja doszycia do projektu kolejnych kończyn :D
Ja też się cieszę, że zacząłeś ten temat - jestem ciekaw jak Ci to wyjdzie w praktyce ;)
Ostatnio czytamłem trochę o UP i o DDD (książki Larmana i Evansa) i z tego co widzę to te dwa podejścia różnią się od siebie. Zasadnicza różnica: w UP proponowanym przez Larmana powstają 2 modele - pierwszy zwie się DOMAIN MODEL, a drugi DESIGN MODEL. Pierwszy przedstawia rzeczowniki ze świata rzeczywistego i relacje pomiędzy nimi. wokół których oscyluje tworzony system i jest inspiracją do stworzenia tego drugiego softwarowego modelu, który jest podstawą do pisania kodu. Tymczasem Evans pisze, że powinien być tylko jeden jedyny MODEL, który tworzą programiści w porozumieniu z domain expertami i później (a może w trakcie ?) go implementują. Oczywiście wszystko dzieje się na drodze iteracyjnego procesu.
Zastanawiam się jak łączycie/zamierzacie łączyć te dwa podejścia ze sobą no i z rzeczywistością w firmie ;)
Prześlij komentarz