Kolejne przypomnienie książki, którą już kiedyś czytałem. Na przestrzeni wielu lat pracy w rozwoju oprogramowania mogę powiedzieć, że wiele rzeczy z tej książki jest wręcz wymagane, jeśli chcemy projektować utrzymywalne aplikacje.

Ubiquitous language, wydzielanie domen i subdomen, tworzenie projektów per subdomena (domena),odpowiednie dobieranie wzorców komunikacyjnych, wyodrębnianie agregatów składających się z encji i w końcu mój ulubiony event storming.

Jeśli jesteś w branży IT, to myślę, że warto sięgnąć po tę książkę i korzystać z niej na wielu etapach swojej pracy. Podstawy wydają się być najważniejsze i bardzo złożone.

Mam również na półce dwie najważniejsze książki o DDD w wersji rozszerzonej, ale nie mam czasu, by się tak zanurzyć... Macie swoją ulubioną książkę z architektury oprogramowania?

Kolejne przypomnienie książki, którą już kiedyś czytałem. Na przestrzeni wielu lat pracy w rozwoju oprogramowania mogę powiedzieć, że wiele rzeczy z tej książki jest wręcz wymagane, jeśli chcemy projektować utrzymywalne aplikacje.

Ubiquitous language, wydzielanie domen i subdomen, tworzenie projektów per subdomena (domena),odpowiednie dobieranie wzorców komunikacyjnych,...

Książkę trudno traktować jako wstęp do Domain Driven Design, bo przedstawia koncepty tego podejścia w sposób ogólnikowy i mało przejrzysty. Nie polecam osobom, które nie miały wcześniej styczności z DDD. Osobiście widziałem kilka prelekcji, które wykorzystywały pojęcia z tego obszaru oraz kurs DevUpgrade, zatem książkę potraktowałem bardziej jako usystematyzowanie i uzupełnienie wiedzy - na tym polu sprawdza się całkiem dobrze.

Książkę trudno traktować jako wstęp do Domain Driven Design, bo przedstawia koncepty tego podejścia w sposób ogólnikowy i mało przejrzysty. Nie polecam osobom, które nie miały wcześniej styczności z DDD. Osobiście widziałem kilka prelekcji, które wykorzystywały pojęcia z tego obszaru oraz kurs DevUpgrade, zatem książkę potraktowałem bardziej jako usystematyzowanie i...

Książka jest trudna w odbiorze ponieważ obfituje w bardzo skomplikowane zdania. Wolałbym żeby autor nie skupiał się tak na skondensowaniu informacji a postawił na przystępność.
Czytając brakowało mi podpisów pod rysunkami, autor zaznacza że jest to celowy zabieg, który ma ułatwić lekturę. W moim przypadku to było utrudnienie.
Pod względem merytorycznym książka warta przeczytania bardziej jednak jako uzupełnienie do już posiadanej wiedzy o DDD.

Książka jest trudna w odbiorze ponieważ obfituje w bardzo skomplikowane zdania. Wolałbym żeby autor nie skupiał się tak na skondensowaniu informacji a postawił na przystępność.
Czytając brakowało mi podpisów pod rysunkami, autor zaznacza że jest to celowy zabieg, który ma ułatwić lekturę. W moim przypadku to było utrudnienie.
Pod względem merytorycznym książka warta...

Jest to moja pierwsza książka/kurs na temat Domain Driven Design (DDD). Czytałem wersję angielską. Autor postawił sobie jako cel skrócone przedstawienie DDD, aby można było zacząć pracować z tą techniką w swoim projekcie od zaraz.

Autor omawia różne pojęcia DDD w krótkich rozdziałach. Posługuje się przykładem implementowania aplikacji do zarządzania projektem Scrum oraz przykładem polis w firmie ubezpieczeniowej. Przechodzi przez Bounded Context, Unbiqious Language, Subdomeny, sposoby integracji między Bounded Context, projektowanie agregatów oraz udziela kilku uwag odnośnie pracy z DDD w projekcie. Autor też mocno promuje architekturę opartą na zdarzeniach (Event Sourcing).

Pisząc delikatnie, książka nie zrobiła na mnie dobrego wrażenia zarówno na temat DDD jak i samego autora. Pierwszym poważnym problemem jest niejasność i wysoka abstrakcja wielu stosowanych terminów. Np. Co to jest Bounded Context według autora:
First, a Bounded Context is a semantic contextual boundary. This means that within the boundary each component of the software model has a specific meaning and does specific things. The components inside a Bounded Context are context specific and semantically motivated. That’s simple enough.

Czyli Bounded Context to jakiś kontekst z granicami, który zawiera w sobie jakieś rzeczy. Nie mówi to dla mnie zbyt wiele. Podobnie jest z wieloma innymi terminami powiązanymi z DDD. Ja rozumiem, że książka miała to przedstawić w skondensowany sposób, ale to poszło o wiele za daleko. Tym bardziej, że drugim poważnym problemem jest masa szumu wokół treści DDD. Zazwyczaj autor zaczyna od DDD, a później potrafi dodawać uwagi/rozpisywać się o takich rzeczach jak SOAP/REST, Event Sourcing, estymowanie zadań, pisanie testów jednostkowych itd. Wiele z tego szumu nie jest tutaj potrzebne oraz według mnie jest przedstawiane w niezbyt przemyślany sposób. Innymi ciekawymi kwiatkami były na przykład takie akapity:
RESTful HTTP will tend to fail for many of the same reasons that RPC does—network and service provider failures, or unanticipated latency. However, RESTful HTTP is based on the premise of the Internet, and who can find fault with the track record of the Web when it comes to reliability, scalability, and overall success?
Albo nie rozumiem tego akapitu, albo autor sugeruje, że nie ma co się zbytnio przejmować problemami infrastrukturalnymi w przypadku korzystania z REST, bo internet jest niezawodny a jak korzystamy z REST to przecież działami przez Internet. A co z serwerami, na których hostowane są nasze aplikacje oraz łączami między serwerami?

Często są też fragmenty typu rób X, a nie rób Y bez żadnego podania powodu dlaczego podejście X jest lepsze od Y. Po prostu rób tak bo autor tak pisze. Innym przykładem dużych niejasności jest jego opis modelowania agregatów. Autor w tej książce nie zaleca stosowania „anemicznego modelu danych”, w którym to encje reprezentują dane, a serwisy operują na danych tych encji. Ale opisał to w ten sposób, że czytelnik ma wrażenie, że autor zaleca umieszczenie wszelkich operacji w encjach z danymi (co np. z zapisem do bazy, wysyłaniem wiadomości do innych usług itp.?). Jak to zobaczyłem to aż spojrzałem do jego drugiej, dłuższej książki i tam jest to zrobione w tradycyjnej formie (serwis, repozytoria). Autorowi chodziło jedynie o to, aby zamiast stosować settery, użyć np. metod biznesowych jak np. sprint.schedule(…) które ustawiają odpowiednie dane wewnątrz kodu encji.

Z pozytywnych rzeczy podobał mi się opis Event Storming do grupowego projektowania funkcjonalności oraz dzielenia się wiedzą za pomocą samoprzylepnych karteczek (ale opisy np. jakiego koloru użyć do jakiego typu karteczki są trochę przesadzone). Podobało mi się też stwierdzenie, że aby odnieść sukces z DDD, trzeba mieć dobrych deweloperów :).

Podsumowując, książka zraziła mnie do DDD i raczej nie sięgnę po inne prace na ten temat przez najbliższy czas. Według mnie najważniejszym przesłaniem tej książki (które przynajmniej dla mnie było i jest bliskie sercu) jest potrzeba bliskiej współpracy deweloperów z ludźmi znającymi wymagania biznesowe oraz pisanie kodu w ten sposób, aby te wymagania były odzwierciedlone w kodzie aplikacji (łącze z sensownymi nazwami operacji i danych). Książki nie polecam.

Jest to moja pierwsza książka/kurs na temat Domain Driven Design (DDD). Czytałem wersję angielską. Autor postawił sobie jako cel skrócone przedstawienie DDD, aby można było zacząć pracować z tą techniką w swoim projekcie od zaraz.

Autor omawia różne pojęcia DDD w krótkich rozdziałach. Posługuje się przykładem implementowania aplikacji do zarządzania projektem Scrum oraz...

Omijać szerokim łukiem. Fatalnie napisana, niejasna, w dodatku w makabrycznym tłumaczeniu.

Omijać szerokim łukiem. Fatalnie napisana, niejasna, w dodatku w makabrycznym tłumaczeniu.

Książka jest świetnym źródłem wiedzy na temat Domain-Driven Design. Pozwala poukładać i uporządkować wiedzę, a przykłady które prezentuje autor są idealnym uzupełnieniem teorii.

Książka jest świetnym źródłem wiedzy na temat Domain-Driven Design. Pozwala poukładać i uporządkować wiedzę, a przykłady które prezentuje autor są idealnym uzupełnieniem teorii.