Warsztat ekspercki to coś więcej niż szkolenie. To praca w kontekście konkretnych problemów.
Tytuł: | Domain Driven Design - projektowanie modeli złożonych domen (część 1) |
Kod: | ddd-workshop-DDD |
Kategoria: | Warsztaty eksperckie DDD |
Forma: | 60% wykłady / 40% warsztaty |
Czas trwania: | 3 dni |
Odbiorcy: | analitycy, architekci, developerzy |
Zapisy: |
Indywidualne zamówienie i dopasowanie dla grupy. |
Logistyka: |
W siedzibie klienta lub w innym dowolnym miejscu. |
Autorski program oparty na 11 latach doświadczenia w stosowaniu i nauczaniu DDD.
Warsztat symuluje krytyczne etapy w pracy nad projektem, w którym mamy do czynienia z nietrywialnymi wymaganiami, kilkoma zespołami i wieloma interesariuszami biznesowymi. Zakładamy też, że odpowiedni model da nam przewagę konkurencyjną.
Pierwszego dnia zaczynamy od Event Stormingu procesowego aby odkryć pod-domeny.
Następnie tworzymy mapę kontekstów, z których dzięki destylacji wyłaniają się generyczne archetypy modeli biznesowych. Na tej podstawie podejmujemy strategiczne decyzje na poziomie współpracy zespołów i izolacji modeli.
Kończymy z projektem krytycznych komponentów ilustrujących problemy techniczne: integracja, optimistic locking, skalowanie.
Drugiego dnia pochylamy się nad wybranymi kontekstami aby stworzyć model taktyczny z wykorzystaniem building blocks. Skupiamy się na granicy agregatów i politykach.
Trzeciego dnia zmieniamy wymagania aby sprawdzić jak zareaguje nasz model. Dodajemy również modelowanie funkcyjne dla dynamicznie zmieniających się reguł.
Formuła warsztatu to kolejne omawianie technik i ich demonstracja przez trenera, po czym uczestnicy w podgrupach samodzielnie przechodzą tą samą ścieżkę na innych wymaganiach. W zadaniach są ukryte pułapki odzwierciedlające realne problemy projektowe, które omawiamy wspólnie po każdym etapie.
Sprawdź naszą implementację przykładowego projektu DDD+CqRS: Sample Projects.
Techniki implementacji DDD (architektura aplikacyjna i systemowa, wykrzyknienie IoC i ORM) są omawiane na szkoleniu DDD-implementacja, które powinno nastąpić w drugiej kolejności, po szkoleniu z zakresu modelowania.
Poznaj ekspertów, którzy mogą poprowadzić Twój Warsztat.
Idea renesansowej pracowni - Bottegi zakłada nieustanną pracę jej członków i dzielenie się jej wynikami.
W swojej pracy spotykając dziesiątki zespołów zauważam wzorce pytań/dylematów/rozterek jakie pojawiają wraz ze wzrostem doświadczenia i świadomości zespołu w stosowaniu DDD. Tak na prawdę pytania te są ogólne a DDD jedynie szybciej do nich doprowadza. Podczas prezentacji przyjrzymy się tym typowym pytaniom na poziomie modelu, architektury i organizacji - spróbuję odpowiedzieć na nie w postaci konkretnych technik i rozwiązań.
Artykuł jest pierwszym z serii tekstów mających na celu szczegółowe przedstawienie kompletnego zestawu technik modelowania oraz nakreślenie kompletnej architektury aplikacji wspierającej DDD.
Artykuł poświęcony zaawansowanym technikom modelowania taktycznego (Building Blocks) oraz technikom strategicznym
Artykuł poświęcony szczegółom implementacyjnym DDD.
Artykuł poświęcony technikom implementacji stosu Write w architekturze CqRS
Artykuł poświęcony technikom implementacji stosu Read w architekturze CqRS
Artykuł poświęcony kompleksowym technikom testowania automatycznego systemu stworzonego zgodnie z DDD
Artykuł poświęcony metodyce modelowania DDD Modeling Whirlpool z elementami BDD i Specification by Example
Artykuł poświęcony modelowaniu przy pomocy DDD.Teskst opublikowany w Software Developer's Journal 08/2011
Techniki zwiększania czytelności kodu.
Artykuł przedstawia koncepcję Wzorców analitycznych – adresujących rozwiązania na poziomie analizy systemowej. Ilustracją na przykładów jest kilka wybranych, w tym najbardziej popularnym z nich: Party – będą one również alternatywą dla typowych naiwnych książkowych modeli struktur organizacyjnych.
Jak połączyć Domain Driven Desing z podejściem architektonicznym Ports and Adapers i Command-query Responsibility Segregation.
Czas, którego nie modelujemy wprost jest czynnikiem, który mści się w projektach. Podczas prezentacji przedstawiono paradygmat zdarzeniowy i wzorzec Process Manager/Saga.
Jak skracać dystans pomiędzy IT a biznesem. Jako developer dowiesz się jak prowadzić sesje "analityczne", aby wynieść z nich maksimum informacji i nie wystraszyć klienta prostokątami z wbitymi w nie dzidami. Zobaczysz też jak przekuwać wiedzę biznesową prost na kod Agregatów DDD.
Przejdziecie przez przykład aplikacji DDD na podstawie, której wytłumaczone zostaną najważniejsze koncepty Domain-Drived Design oraz popularne techniki towarzyszące.
W trakcie prezentacji przejdziemy przez ES procesowy i taktyczny. Zajmiemy się odkrywaniem pod-domen, destylacją Bounded Context i określaniem granicy agregatów. Na koniec zastanowimy się dlaczego storming kończy się niepowodzeniem z powodu braku umiejętności miękkich.
W trakcie prezentacji dowiesz się jak przekładać informacji ze stormingu na decyzje architektoniczne dzięki strategicznym narzędziom DDD: destylacji kontekstów i mapowaniu kontekstów. Skupimy się na kilku konkretnych heurystykach, które podpowiadają jak dążyć do modularnego monolitu lub microservices, które mają realną autonomię dzięki: projektowani single source of truth i unikaniu single point of failure.
W trakcie prezentacji przejdziemy od niepokojących symptomów na poziomie kodu, wytropimy dzięki nim błędne decyzje architektoniczne, na poziomie modularyzacji i integracji, aby dojść do błędów na poziomie analizy. Następnie cofniemy czas, przeprowadzając rzetelną analizę granic, poprzez technikę Event Stormingu Procesowego, zaprojektujemy moduły, dzięki strategicznym technikom Domain-driven Design i skończymy z kodem, który właściwie jest... czytelny jak proza.
Miało być tak pięknie... Przykleiliśmy kilkaset kolorowych karteczek, zrobiliśmy im zdjęcie/screenshota i wrzuciliśmy na twittera i linkedin, przybiliśmy sobie piątki a po roku nasze mikroserwisy i lambdy pływają w sosie bolognese.
Co poszło nie tak? Jak mogliśmy znowu przeoczyć Single Source of Truth i wprowadzić kilkanaście Single Point of Failure? Najtrudniejsze w programowaniu są umiejętności miękkie.
Z prezentacji dowiesz się:
- jak zadawać pytania, które nie sugerują odpowiedzi
- jak formułować typowe pytania techniczne tak aby adresowały problemy biznesowe
- jak zaadaptować swój interfejs do interfejsu osoby o zupełnie innej historii edukacji
- czyli jak rozpoznawać preferencje kognitywne rozmówców i się do nich dopasowywać
W trakcie prezentacji zobaczysz dwa systemy realizujące te same wymagania. Przyjrzymy im się z punktu widzenia: modularyzacji, kodu warstwy aplikacyjnej i kodu warstwy bogatego modelu dziedzinowego. Architektura pierwszego będzie oparta o naiwną analizę, pospieszną modularyzację i krótkowzroczną integrację. Architektura drugiego będzie oparta o kilka rozdziałów z książek będących biblioteką rozwiązań typowych problemów biznesowych - archetypów. W trakcie prezentacji dowiesz się czym się kierować podczas wyszukiwania archetypów, które na pierwszy rzut oka nie są podobne do "specyficznych systemów" nad którymi pracujesz na co dzień. A przy okazji zobaczymy jakie są konsekwencje posługiwania się sprawdzonymi rozwiązaniami w porównaniu do rozwiązań wynikających z tak zwanej intuicji.
„Wszystko jest na miejscu i wszystko ma swoje miejsce” - cytat Benjamina Franklina jest chyba najlepszym podsumowaniem strategicznych technik DDD.
Pierwszą decyzją, jaką podejmujemy podczas modelowania z wykorzystaniem DDD, jest określenie tych miejsce w całej „rozciągłości” systemu, w których będziemy stosować techniki DDD.