DDD a praktyka

0

Czy ktos z tu obecnych uzywa DDD w projekcie? Mam podejrzenie ze DDD jest cool na prezentacje na devoxx, ale zastosowanie teog w praktyce jest na tyle trudne, ze malo kto tego uzywa. Mam racje?

1

Pracuję w projekcie, który od strony technicznej "aspiruje do bycia zgodnym z DDD" tzn. ma jego pewne elementy tylko trochę warstwy uciekają ale mamy plan to poprawić, wiem też, że w firmie są projekty, które mocno poszły w DDD. Od strony technicznej nawet uważam, że jeśli aplikacja robi coś więcej niż zapisywanie formularza do bazy to jest to prostsze niż standardowy model, który pewnie większość zna. Jednak to co jest najtrudniejsze w DDD to część związana z rozmową z biznesem. Z taką faktyczną pracą z ekspertami domenowymi, robieniem porządnego event-stormingu itd. się osobiście nie spotkałem, ale też i za wiele projektów nie widziałem w życiu.

1

Podejrzewam, że postrzegana trudność wprowadzania DDD może wynikać z tego, że w prezentacjach DDD jest często łączone z CQRS i ES podczas, gdy DDD może spokojnie istnieć bez pozostałych dwóch.

Istotą DDD jest to, że tworzenie super-modelu wspólnego dla wszystkich funkcjonalności jest tym bardziej niepraktyczne im więcej jest tych funkcjonalności (tzn im większy jest system). Dlatego wydziela się Bounded Contexts, duplikuje struktury danych jeżeli występują w wielu Bounded Contexts i na ich styku je tłumaczy. Pokazane jest to na https://martinfowler.com/bliki/BoundedContext.html . Wewnątrz każdego Bounded Context mamy Ubiquitous Language, używany konsekwentnie zarówno przez biznes jak i programistów.

CQRS, ES, Eventual Consistency itd są natomiast dalszymi krokami ku reaktywnym mikroserwisom. Opisane jest to tutaj: https://www.oreilly.com/ideas/the-evolution-of-scalable-microservices . CQRS, ES, Eventual Consistency umożliwiają efektywne skalowanie warstwy zapisu i odczytu.

DDD można łatwo wymusić już na etapie Microliths (pojęcie z przytoczonego artykułu). Jeśli każdy mikrolit ma własny prywatny model biznesowy oraz własne publiczne klasy DTO służące do implementacji API RESTowego, a sam podział na osobne mikrolity ma sens z poziomu biznesowego to mamy w zasadzie DDD.

PS:
O DDD, CQRS, ES itd czytam od stosunkowo niedawna, więc mogłem coś przekręcić :]

0

Projekty nad którymi pracowałem nie stosowały religijnie DDD ale na pewno czerpały z niego wiele rzeczy - na przykład nie próbowanie zrobienie jednego modelu do użycia w wielu modułach/serwisach i stosowanie "lokalnego" nazewnictwa odpowiedniego do kontekstu użycia. Nie mieliśmy dobrego kontaktu z klientami (niestety charakterystyka firmy) więc na pewno nie było to czyste DDD. To jest trochę tak jak z TDD - też nie używam tego do wszystkiego, ale zawsze jak zaczynam pisać kod to świeci się lampka "jak to przetestować unitami" i przed review robi się refactor.

1 użytkowników online, w tym zalogowanych: 0, gości: 1