Domain-Driven Design – Eric Evans

W końcu przyszedł czas na dogłębne wgryzienie się w temat Domain-Driven Design. Pod głównym założeniem mogę podpisać się obiema rękami: do stworzenia dobrego programu umożliwiającego efektywne utrzymanie, wprowadzanie zmian i rozszerzeń, potrzebne jest dobre zrozumienie danej dziedziny.
Proste rozwiązania mogą opierać się na dużych uproszczeniach. Problem powstaje, kiedy złożoność dramatycznie rośnie i wymyka się spod kontroli. Programiści nie mogą już na tyle dobrze zrozumieć programu, aby go zmieniać w prosty i bezpieczny sposób.
Zmiany w złożonym systemie to test naszego rozwiązania. Jeśli dość wiernie odwzorowuje on świat rzeczywisty, rozszerzenie będzie stosunkowo proste. Jeśli natomiast, zamiast podążać za na pojęciami biznesu (dziedziny) i ich zależnościami, tworzyliśmy własne modele oderwane od tego świata, zmiany mogą wywracać systemy do góry nogami.
Autor zauważył zatem potrzebę poznania i zrozumienia świata danej dziedziny biznesu. Jednego tylko nie rozumiem.  Z dotychczas przeczytanych 10% książki wyłania mi się taki obraz: autor wie, że to potrzebne. Wie także, że to zadanie bardzo trudne. Opisuje swoje wyzwania w odkrywaniu tych modeli dziedziny. Mam wrażenie, że próbuje lepiej lub gorzej, ale na własną rękę wypełnić lukę między programistami a ekspertami dziedzinowymi (interesariuszami). Pisze nawet: „Wielu utalentowanych programistów nie ma zbyt dużo powodów, by poznać dziedzinę, w której pracuje, a jeszcze mniejsza ich liczba podejmuje wyzwanie udoskonalenia swoich umiejętności projektowania dziedzinowego. Ludzie dysponujący wykształceniem technicznym zadowalają się przeliczalnymi wymiernymi problemami, które stanowią wyzwanie dla ich technicznych umiejętności. Praca nad dziedziną jest nieprzyjemna i wymaga dużej ilości skomplikowanej wiedzy, która nie wydaje się zwiększać umiejętności programistów.”
I tu powinien wychylić się podskakujący, z ręką wyciągniętą wysoko w górę, analityk. Przecież macie od tego mnie! Ja to bardzo lubię! Znam mnóstwo narzędzi, żeby robić to zadanie efektywnie! Zrobię to lepiej, szybciej i z większą przyjemnością.
Autor jednak wychodzi z negatywnych doświadczeń z projektów waterfallowych. O ile zaczął pracować nad książką 15 lat temu, wierzę, że wiele się od tej pory zmieniło. To, co kiedyś stanowiło problem, znalazło od tego czasu już wiele rozwiązań a przynajmniej usprawnień. Jedno natomiast jestem w stanie zrozumieć – krytykę komunikacji w jednym kierunku. Klient coś powiedział, analityk to jakoś przedstawił, a gdy wpadło to do programistów, był to koniec komunikacyjnej ścieżki. Otworzenie komunikacji także w drugim kierunku na pewno dało wiele korzyści. Jest to jednak przyjęcie pewnego modelu pracy, w którym analitycy także działają.
Sztuką jest właściwe przetwarzanie wiedzy – zamienianie potoków informacji w jedynie istotne strużki. Model, czyli wybrany fragment interesującej nas rzeczywistości, upraszcza skomplikowany świat do postaci, która będzie użyteczna dla efektywnej realizacji zadania – stworzenia wspierającego oprogramowania. Pozwala jasno komunikować się klinentom (biznesowy, ekspertom dziedzinowym) z analitykami, zespołami między sobą – umożliwia stosowanie wszechobecnego wspólnego języka.
Czytam dalej 🙂 A Wy, programiści pamiętajcie, my, analitycy, jesteśmy tu i dziką przyjemnością zanurzymy się w meandry wiedzy dziedzinowej, przedstawiając Wam to, co najważniejsze i zostawiając wam czas na to, co lubicie robić najbardziej.
Więcej o modelu dziedziny przeczytasz tu: https://analizait.pl/2012/model-dziedziny-odkrywamy-tajemnice-swiata-uzytkownika/