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: http://analizait.pl/2012/model-dziedziny-odkrywamy-tajemnice-swiata-uzytkownika/

Hania Tomaszewska
8 lat temu odkryłam, że analiza biznesowa to genialna rzecz. Od tamtej chwili zbieram doświadczenia w różnych firmach, branżach i projektach. Pracuję na etacie, prowadzę bloga, tworzę kursy, prowadzę szkolenia i konsultacje. Pomagam analitykom doskonalić warsztat pracy i rozwijać się, managerom układać procesy i rozwijać pracowników oraz przedsiębiorcom, aby rozwiązania IT wspierały ich działalność.

4 KOMENTARZE

  1. Bardzo celne. Czytając artykuł przy okazji można zauważyć jak techniki projektowe wpływają na postrzeganie rzeczywistości i poprzez wartościowanie jej mają na nią wpływ. Chyba minęła epoka tworzenia „wiekopomnych” dzieł, w których wiedza jest zbierana na przestrzeni dekad i publikowana jako monolit. Publikacje poprzez blogi pozostawiają ten tradycyjny sposób daleko w tyle. Ciekawym na to przykładem jest coś z zupełnie innego obszaru – historia tworzenia książki i scenariusza filmu „Marsjanin”.

    • Ma Pan na myśli monolit jako grube książki? To prawda, że potrafią powstawać długo. Jednak ma to swoje zalety. Można chociażby spojrzeć na listę bardzo zasłużonych w branży osób, które brały udział w weryfikacji książki. Przeszła wiele udoskonaleń, zanim ujrzała światło dzienne. Na blogach pewnie nie ma aż tak wielkiej staranności. Mi też brakuje takiego całościowego spojrzenia. Na blogach mamy tematy wyrwane z kontekstu i trzeba samemu poukładać to w głowie. Książka daje jednak takie spojrzenie całościowe. I mimo pewnych aspektów, na które można przymrużyć oko, ta wiedza, myślę, że jest na tyle uniwersalna, że wiele tez (np. zrozumcie dziedzinę i odwzorujcie ją w systemie) nie przeterminuje się szybko, o ile w ogóle.

  2. Nie można tu zapominać o branżowych modelach referencyjnych wypracowanych przez telco, bankowców, ubezpieczeniach, energetyce czy innych. Dają największą wartość gdy mówimy o produktach lub o integracji czy interoperacyjności

ZOSTAW ODPOWIEDŹ