Korzyści z DDD z punktu widzenia właściciela firmy softwareowej

... i jej klientów.

Połączenie BDD z DDD

Community Behavior Driven Development zaczyna się reflektować, że metodyka daje bardzo płytkie rozumienie domeny.
W artykule  http://www.infoq.com/news/2015/02/bdd-ddd znajdziecie link do prezentacji https://skillsmatter.com/skillscasts/6240-taking-back-bdd która pokazuje jak i dlaczego integrować BDD i Domain Driven Design.

O ile zgadzam się co do idei, to prezentowana implementacja wydaje się być po prostu szkodliwa. Historyjka akceptacyjna operuje na obiektach domenowych, zamiast na wyższej warstwie, czyli serwisach aplikacyjnych lub CommandHandlerach.

Jaka jest konsekwencja? Historyjka powiela logikę wyższej warstwy. Nie tędy droga... Pomylono po prostu Domain Story z User Story i stąd taki kuriozalny efekt. Może gdyby prelegent napisał nieco kodu, to by uświadomił sobie błąd w rozumowaniu;)

O powierzchowności User Story mówiłem tutaj: https://www.youtube.com/watch?v=z0y3IPJDyp0


//======================
Podobne problemy napotkamy stosują Spec by Example. Nie chcę być źle zrozumiany, nie twierdzę, że BDD czy SBE są błędne, są po prostu niewystarczające dla nietrywialnych domen.

Inna obserwacja: czy ludzie biznesu na pewno potrafią dobrze operować przykładami? Ile przykładów można zmieścić w pamięci podręcznej mózgu? Może przykłady są dobre w początkowej fazie poznawania domeny a później wygodniej od nich abstrahować? Odpowiedź brzmi oczywiście: "to zależy". Ale zależy od czego? Od nawyków kognitywnych konkretnego człowieka. Niektórzy preferują abstrakt a inni konkret, jeszcze inni najpierw jedno, później drugie.

Więcej na ten temat można zacząć eksplorować np tutaj: http://en.wikipedia.org/wiki/Learning_styles#David_Kolb.27s_model

Modeling Whirlpool z DDD idealnie integruje wszystkie style uczenia (poznawanie domeny jest uczeniem się jej) z Cyklów Kolba.

Video z prezentacji na JDD 2014: JPA i DDD

Mapowanie relacyjnono-obiektowe prawdziwych obiektów.

Slajdy: http://prezi.com/fsvd1xnvecff/mapowanie-relacyjno-obiektowe-prawdziwych-obiektow/

Główne tezy:

• nie używaj lazy loadingu
• uważaj na typ kolekcji
• rozważ 3 sposoby optimistic locking
• wzorzec Repository ma więcej sensu się wydaje
• CQRS na ratunek

Do poczytania na spokojnie http://bottega.com.pl/pdf/materialy/receptury/orm.pdf

...a tu więcej do poczytania: http://bottega.com.pl/artykuly-i-prezentacje

Jak wciągnąć eksperta domenowego w wir modelowania

Slajdy: http://prezi.com/ihs7d0t_0mci/jak-wciagnac-eksperta-domenowego-w-wir-modelowania-wizualne-i-lingwistyczne-techniki-ddd/

Główne tezy:

• Model jest narzędziem komunikacji
• Przydawki są ważne:)
• Można myśleć funkcyjnie i programować obiektowo
• Proces jest pochodną domeny
• User story jest słabe - potrzebujesz domain story
• Refaktoryzacja bez zrozumienia domeny jest zgubna

Nie koduj, pisz prozę - techniki lingwistyczne wychodzące poza Clean Code!

Confitura opublikowała moją prezentację z tegorocznej edycji.

(dzięki za fajny montaż slajdów)

Gdyby ktoś chciał śledzić animację slajdów, to można tutaj: https://prezi.com/ktgmacy7hcfa/nie-koduj-pisz-proze/

Microservices w kontekście DDD

Mamy nowy buzowrd: mokroserwis, który zdążył być już w typowy da naszej branży - Montypythonowy - sposób wypaczony:)

Autor artykułu Microservices: Usage Is More Important than Size stawia retoryczne pytanie:
czy mikroserwis to
- SOA, które wreszcie doczekało się poprawnej interpretacji (bez ESB i smutnego SOAP)
- czy może stara "dobra" CORBA i RMI tylko, że podana na REST wraz ze wszystkimi smutnymi konsekwencjami zbytniego rozproszenia?

Kolejne figury retoryczne pojawiają się w tekście Microservices? What about Nanoservices?: Sto linijek to jeszcze makro-serwis czy już nano-serwis (funkcjonalność a nie serwis), który jest antywzorcem?

Mierzenie linijek kodu od linijki to jak zwykle znak, że "coś się dzieje";)

Patrząc z dystansu widać to co zwykle: onanizm techniczny zamiast zrozumienia jaki problem próbujemy rozwiązać.

Wydaje mi się, że gdyby za definicję zakresu mikroserwisu przyjąć: API dla Bounded Context z DDD, to wszystko stałoby się jasne...

Video z Confitury

Właśnie się zorientowałem, że od jakiegoś czasu dostępna jest moja prezentacja z tegorocznej Confitury: Model jest wszystkim czego potrzebujesz (w aplikacjach biznesowych) - czyli czego nauczyłem się podczas 6 lat praktykowania i nauczania DDD).

DDD-Leaven v2

Po kilku nieprzespanych nocach opublikowaliśmy drugą wersję projektu DDD-Leaven
https://github.com/BottegaIT/ddd-leaven-v2

Podobnie jak w wersji 1, celem jest udostępnienie projektu, który pozwala szybko rozpocząć pracy z technikami DDD poprzez zapewnienie szkieletu technicznego (chciałbym w tym miejscu podkreślić nieoceniony wkład Rafała Jamroza).

Natomiast w wersji drugiej rozszerzyliśmy znacznie domeny biznesowe aby zilustrować techniki modelowania - zaawansowane wykorzystanie Building Blocks, ale przede wszystkich techniki lingwistyczne oraz techniki dokumentowania modelu i prowadzenia sesji modelowania z Ekspertem Domenowym.

Wiele z tych technik to implementacja lub nawet rozwinięcie technik, jakie poznaliśmy na wiosennym IDDD Tour wraz z eksperymentalnymi technikami rozwijanymi w ThoughtWorks.

Niektórych technik nie "widać" poprzez kod, dlatego będę je opisywał w kolejnych odcinkach serii DDD h4x.

Wiki jest w trakcie tworzenia, ale skalowalna "mapa" powinna pomóc w zwiedzaniu źródeł: http://prezi.com/akrfq7jyau8w/ddd-cqrs-leaven-v20/

//============================

Aby zacząć od konkretów technicznych: kilkanaście osób pytało o przykład implementacji założeń z tekstu: http://art-of-software.blogspot.com/2013/06/mapowanie-relacyjno-obiektowe.html
Teraz dysponuję źródłami, które mogę udostępnić: https://github.com/BottegaIT/ddd-leaven-v2/blob/master/src/main/java/pl/com/bottega/ddd/support/infrastructure/repository/jpa/GenericJpaRepository.java

JUG: 19-20 listopada Trójmiasto - DDD i testowanie

W imieniu swoim jak i Rafała zapraszam na warsztaty jakie będziemy prowadzić w przyszłym tygodniu w Gdańsku w ramach JUG korzystając z gościnności Spartez:

Modeling Whirlpool - warsztaty z modelowania DDD: https://www.eventbrite.com/e/modeling-whirlpool-warsztaty-z-modelowania-ddd-sawek-sobotka-tickets-9324093615

Jak wyprowadzić słabe i smutne testy na prostą: https://www.eventbrite.com/e/jak-wyprowadzic-sabe-i-smutne-testy-na-prosta-rafa-jamroz-tickets-9324528917

Wrocław 28 i 29 października

Szybki ogłoszenie:

Zapraszam wszystkich chętnych na otwarte spotkania w najbliższym tygodniu we Wrocławiu

• 28 października: Wrocław JUG - prezentacja na temat testowania automatycznego (dla programistów): https://groups.google.com/forum/#!topic/wroclaw-jug/tR-xgr0X-Wo
• 29 października: DDD-WRO - spotkanie poświęcone technikom modelowania: http://www.meetup.com/DDD-WRO/events/146833852/

Przyczyna czy skutek?

Po 6 latach praktykowania DDD, prowadzenia i uczestniczenia w licznych warsztatach i szkoleniach chyba wreszcie zrozumiałem o co chodzi w całym tym Domain Driven Design...

Wszystko dzięki trafiającemu (jak zwykle) w sedno postowi Jarka Żelińskiego: Czy aby na pewno zarządzamy procesami biznesowymi?

Wstęp

Patrząc na warstwową architekturę systemu opartego na DDD mamy:

UI
----------------------
Application (API)
----------------------
Domain Model
----------------------
Infrastructure

(możemy użyć również popularnej ostatnio metafory Heksagonu - ale nie wpływa to na wywód)

W warstwach UI+APPlication możemy możemy mieć zamodelowany proces biznesowy. Ew. szczególnym klientem do API (również obok np apliakcji webowej) może być silnik procesów biznesowych.
W warstwie Domain rezyduje model bazowych reguł biznesu ("fizyki" biznesu) zamodelowany przy pomocy Building Blocks DDD, które chronią niezmienniki. Więcej o BB: DDD krok po kroku.

Problem: Od czego zacząć modelowanie?

Od procesu czy od domeny? Innymi słowy: od ogółu czy od szczegółu?
W Domain Driven Design zaczynamy (niespodzianka) od modelowania warstwy Domain. API i proces to rzecz wtórna.

To zależy...

Jak w każdym nietrywialnym przypadku, odpowiedź  na pytanie zależy od kontekstu.

W przytoczonym na wstępie artykule znajdziemy olśniewającą (przynajmniej dla mnie) wskazówkę:

• czy proces biznesowy wyłania się z reguł niższego rzędu - innymi słowy model domenowy nakłada ograniczania, które wyznaczają "trajektorię" procesu, który lawiruje pomiędzy nimi niczym strumień rzeki w jej korycie (posługując się metaforą Jarka)
• czy może to raczej proces narzuca kształt modelowi domenowemu?

W DDD podchodzimy do modelu w ten pierwszy sposób - zaczynamy od domeny, czyli fundamentalnych reguł i ograniczeń, w które wpasowuje się proces.

Trudne pytanie

Po czym poznać z którą sytuacją masz do czynienia? Najpewniej w dużym systemie mamy obie...

//===============================

To w sumie wydaje się oczywiste, ale sztuką jest tak ubrać myśl w słowa, aby (np przez porównanie dwóch podejść) ująć ideę w jednoznaczny sposób.

Mapowanie relacyjno-obiektowe prawdziwych obiektów – rzecz o DDD i JPA

Czy wiesz, że:

• Lazy Loading nie ma sensu
• Mapowanie @OneToMany z wykorzystaniem tabeli linkującej (domyślne zachowanie hibernate) nie ma sensu
• Blokowanie Optymistyczne oparte jedynie na @Version nie ma sensu

...jeżeli stosujesz zasady Object Orinted i JPA (lub inny maper relacyjno-obiektowy).


Jeżeli powyższe tezy targnęły Twoimi emocjami, to zapraszam do lektury najnowszego artykułu: Mapowanie relacyjno-obiektowe prawdziwych obiektów – rzecz o DDD i JPA (do pobranie całkowicie free), który ukazał się w najnowszym numerze programistamag.pl (wakacyjny numer o podwójnej objętości dostępny w Empikach lub w formie elektrycznej).

Zapraszam do śledzenia całej serii Laboratorium Bottega - Receptury projektowe – niezbędnik początkującego architekta.

Open/closed principle - zastosowanie na poziomie architektury aplikacji oraz metafory wizualne

"Kod powinien być otwarty na rozbudowę jak kwiat lotosu o świcie i zamknięty na zmiany jak kwiat lotosu o zmierzchu" - jako początkujący projektant natknąłem się kiedyś w jednej z książek na takie "Buddyjskie" wyjaśnienie Open/Closed Principle - jednej z zasad SOLID.

Jednak jak w praktyce zastosować tą zasadę? Czy aplikuje się ona jedynie na poziomie Object Oriented Design czy również na poziomie architektury aplikacyjnej?

W najnowszym artykule "Zarządzenie złożonością przez trójpodział logiki – Open/closed principle w praktyce" opublikowanym na łamach programistamag.pl przedstawiłem swoje przemyślenia na temat OCP, w których integruję:

• ODD, 
• podstawy podejścia funkcyjnego, 
• Building Blocks wchodzące w skład Domain Driven Design,
• architekturę na poziomie aplikacyjnym.

W artykule chciałbym zaproponować Wam swego rodzaju "framework mentalny", który pozwala zmierzyć się ze złożonymi problemami dzieląc logikę na 3 kategorie:

• stabilną - której kod relatywnie rzadko podlega zmianom
• domknięcia logiki - które nie polegają zmianom a rozbudowie
• wybór domknięć - zmiany enkapsulowane w fabrykach (zgodnie z regułą Uncle Boba: "instrukcje switch są dozwolone jedynie w czeluściach fabryk":)

Zatem jest to meta-model, który pozwala na tworzenie modeli problemów zgodnych z OCP. W artykule znajdziecie również propozycję 3 rodzajów wizualizacji graficznej OCP: jedno, dwu i trójwymiarową - w zależności od preferencji kognitywnych...

Artykuł do pobrania (jak zwykle całkowicie za darmo) tutaj: http://bottega.com.pl/artykuly-i-prezentacje

Materiały z konferencji 33rd Degree

Oto obiecane materiały:

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego - problemy, strategie, taktyki, techniki i narzędzia






Model jest wszystkim czego potrzebujesz (w aplikacjach biznesowych) - czyli czego nauczyłem się w ciągu 6 lat stosowania i nauczania DDD






Dodatkowo dla osób, które pytały o inne prezentacje:

Architektura Ports & Adapters
Wstęp do DDD: Domain Driven Design - A place for everything and everything in its place
Architektura CqRS: Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw

Projekt referencyjny: DDD & CqRS Sample Leaven


//==========================

Jak zwykle feedback odnośnie prezentacji mile widziany - może być na prv.

100 mandaysów za dodanie jednego checkboxa?!?

Standardowa scenka: spotkanie tak zwanego "biznesu" z tak zwanym "IT"; dyskusja nad "małą kosmetyczną zmianą" polegającą na "dodaniu jedynie małego checkboksa".

Na minach "IT" najpierw pojawia się grymas namysłu, a następnie ekspresja (nie mikro-ekspresja) zagłady i katastrofy. W wyobraźni ujrzeli trzęsienie ziemi, która kruszy katedrę, którą budują od x miesięcy/iteracji/cokolwiek. "IT" przełyka ślinę i odpowiada: "zajmie nam to 100 mandaysów".

Mina "biznesu":

Dalszy rozwój scenariusza może przebiegać różnie w zależności o relacji - czy mamy negocjacje klient-dostawca, dział biznesowy-dział it, itd.

Typową dziecinną techniką jest zaniżanie o połowę, ale IT już wie, że "oni zawsze zaniżają", więc defaultowo  zawyża, jednak biznes, wie, że "oni defaultowo zawyżają", więc zaniża 4-krotnie, itd... wszyscy traktują się nawzajem jak by druga strona była opóźniona.

W każdym jednak przypadku "IT" jest na przegranej pozycji. Podczas gdy "my" doskonalimy się we frameworkach, wzorcach i architekturach, "oni" zdobywają siódmy czarny pas w NLP i technikach manipulacji wszystkim czym da się manipulować...

Skąd bierze się takie niezrozumienie powagi zmiany?

Najprawdopodobniej obie strony mają w swoich umysłach inne modele mentalne problemu oraz jego złożoności.

Bywalcy konferencji oraz czytelnicy książek przyprawionych nutką Agile próbują posiłkować się metaforą "Długu technicznego", który został kiedyś zaciągnięty i oto nadeszła chwila, kiedy trzeba go spłacić. "Ale jaki dług, przecież działa!" - możemy usłyszeć w odpowiedzi.

Gdyby istniał wspólny model domeny problemu, wówczas każdy uczestnik projektu "czułby" intuicyjnie powagę zmiany. Ew. naiwne uproszczenia dokonywane z wielu (zwykle racjonalnych) powodów, mogłyby być dokonywane ze świadomością konsekwencji. Uświadomiony dług techniczny.

Dla przykładu: powyżej widzimy model budynku wydrukowany przez drukarkę 3D. Nawet osoba nietechniczna intuicyjnie poczuje, że "postawienie o tutaj (wskazuje palcem na dach) lądowiska dla helikoptera" będzie "nieco" kosztowne. Trzeba przecież znacznie rozbudować konstrukcję nośną albo jeżeli chcemy ją zachować wymienić słupy na tworzywo wykradzione z NASA;)

Spróbujmy osiągnąć taki poziom świadomości gdyby obie strony siadły do: a) rysunków technicznych, b) dokumentów wizji, przeczuć i życzeń zwanych czasem dumnie artefaktami analitycznymi.

Ten przydługi wstęp miał być zachętą do zapoznania się z ostatnim z publikowanej w programistamag.pl serii "DDD krok po kroku": Modeling Whirlpool – iteracyjny proces modelowania (dostęp jest całkowicie darmowy).

Modeling Whirpool jest zwinnym procesem tworzenia wspólnego modelu, który jest zrozumiały również dla Eksperta Domenowego oraz implementowalny 1:1 w kodzie źródłowym - żadnych poziomów abstrakcji, które tworzą luki semantyczne.

//====================================

W styczniowym numerze rozpoczynam nową serię: "Niezbędnik początkującego Architekta", wktórej znajdziecie systematyzację (mam nadzieję) wiedzy bazowej oraz kilka sprawdzonych receptur.

Zainteresowanych DDD i Modeling Whirlpool zapraszam na konferencję 33rd Degree - prezentacja i warsztaty.

Testowanie automatyczne - artykuł

W najnowszym numerze programistamag.pl ukazał się kolejny artykuł z serii DDD: "Kompendium testowania aplikacji opartej o DDD – problemy, strategie, taktyki i techniki".

Artykuł można pobrać również tutaj: http://bottega.com.pl/artykuly-i-prezentacje (całkowicie free:).

Problem testowania automatycznego został osadzony w kontekście DDD, ale traktuje o testowaniu w ogólności, tak więc lektura powinna być pożyteczna dla każdego programisty i projektanta. Proponujemy w nim nieco inne spojrzenie na klasyczną już piramidę testów - dosłowne mapowanie piramidy na architekturę warstwową oraz nieco inne spojrzenie na pokrycie kodu testami.

Treść została uporządkowana wg struktury: Problemy, Strategie, Techniki, Taktyki i Narzędzia.

Jest to autorska metodyka opracowana w naszej firmie, którą stosujemy podczas coachingu z zakresu testowania automatycznego, składająca się z 2 etapów:

• W fazie analizy sytuacji poruszamy się ścieżką top-down aby zdiagnozować cele na każdym poziomie w kontekście poziomu wyższego.
• Natomiast w fazie wdrażania (coachingu) poruszamy się ścieżka bottom-up aby skupić się tylko na tych aspektach, które wprowadzają największą wartość.

Jeżeli wdrażasz (lub planujesz wdrożyć) zmiany we własnej organizacji to zachęcamy do wypróbowania tego podejścia i podzielenia się spostrzeżeniami.

//=======================================

Jednak główne przesłanie artykułu to: "unikaj pracy z serwerem aplikacji i bazy danych". Ile czasu zajmuje Ci cykl od momentu wciśnięcia ctrl+s w swoim IDE do przekonania się czy zmiany w kodzie są poprawne? Kilkanaście minut? Próba hotdeploymentu, przeładowanie aplikacji, które kończy się restartem serwera, przygotowanie danych, przeklikanie kilkunastu formularzy (każdy po kilka zakładek z kilkunstaoma polami) aby wreszcie zobaczyć np złą kwotę po naciśnięci "Zatwierdź" na ostatnim formularzu.

Czy po to studiowałeś/studiowałaś 5 lat?

Dzięki wydzieleniu warstwy domenowej, a w niej posługiwaniu się Bulding Blocks zgodnie z zasadami DDD osiągamy wysokie testability kodu, które pozwala na pracę z pojedynczymi fragmentami modelu przy pomocy testów jednostkowych (tanich w stworzeniu, bo unikamy sytuacji gdy potrzeba stworzyć Mock/Stub/Fake).

DDD krok po proku - dostęp do artykułów i plany kolejnej serii

Ostatnie pół roku działalności bloga można podsumować krótko: marazm:)

Przyczyną jest oczywiście nawał pracy. Miesięczny "zasób weny" inwestowałem w projekt tworzenia serii artykułów "DDD krok po kroku", która ma na celu przedstawienie technik z zakresu architektury systemu, architektury aplikacji oraz implementacji projektu opartego na podejściu DDD.

Artykuły są publikowane co miesiąc w  programistamag.pl, natomiast dzisiaj - dzięki uprzejmości redakcji - możemy je udostępnić w formie niekomercyjnej - do pobrania tutaj.

W serii zaplanowane są jeszcze 2 artykuły:

• Kompendium testowania automatycznego - problemy, strategie, taktyki i techniki
• Kompleksowy proces modelowania DDD "Modeling Whirlpool" (z elementami BDD i Specification by Example)

Oba artykuły zostaną również udostępnione na blogu i będą ekstraktem całej naszej aktualnej firmowej wiedzy, którą stosujemy w projektach i pracy coachingowej z zespołami.

//=====================================

W planach mam kolejną serię artykułów, tym razem przeznaczoną dla początkujących programujących projektantów i programujących architektów. Seria będzie miała na celu wprowadzenie początkujących w świat podstawowych pojęć jak również zaawansowanych koncepcji oraz konkretnych rozwiązań typowych problemów.

Tematy z założenia nie będą ze sobą powiązane, jednak chciałbym wprowadzać bazowe pojęcia w początkowych artykułach aby na ich bazie budować bardziej złożone struktury.

Przykładowe tematy:

• Trzy smaki odwracania (i utraty) kontroli 
• Programowanie funkcyjne w Javie - kiedy i po co?
• Fabryka dekorowanych strategii - czyli o trójpodziale logiki
• Deus ex Machina Stanów - dlaczego potrzebujesz jej w modelu biznesowym i jak zrobić ją źle 
• Lazy Loading w pułapce czasu - błędy logiczne, które prawdopodobnie masz i o których prawdopodobnie nie wiesz
• Emulacja Traits w Javie - Role Object Pattern
• Mock czy Stub? - Command-query Separation prawdę Ci powie

Jeżeli ktoś chciałby "zamówić" jakiś temat to czekam na propozycje.

ORM - "The Vietnam of Computer Science"

...cytat Teda Newarda rozbawił mnie szczerze - ale to śmiech przez łzy. Martin Fowler natomiast pyta: Ale co w zamian?

Możemy uciec się do rozwiązań typu Datoms (Encja, Atrybut, Wartość, Timestamp) lub bardziej "semantycznego" Event Sorcingu.

Jednak są to rozwiązania specyficznych klas problemów (podróże w czasie, wektory uczące dla Sztucznych Sieci Neuronowych) lub problemów skali Googl/Twitter/Facebbok - mimo, że nie pracujemy w tych firmach, to lubimy się na nie powoływać w swych elaboratach architektonicznych:)

Natomiast w typowych systemach biznesowych wystarczy przyjęcie prostych i racjonalnych zasad doboru odpowiedniego młotka do odpowiedniej klasy problemu:

• Obiekty persystentne to Agregaty, których granice są wyznaczane wg dobrych praktyk DDD: np. modelowanie niezmienników oraz modelowanie jednostki zmiany biznesowej
• Do persystencji Agregatów używamy ORM, ponieważ dobrze zakreślone granice agregatów (w tym unikanie zbędnych połączeń) rozwiązują większość problemów
• Do wydajnego odczytu danych przekrojowych nie używamy ORM - nie służą do tego typu zadań 

Proste, łatwe i... przyjemne:)
W razie problemów z wydajnością warto spróbować różnych form separacji z podejścia: Command-query Responsibility Segregation.

//==========================

Więcej w archiwalnym poście, natomiast rozwinięcie w najbliższym numerze programistamag.pl

programistamag: CqRS

Zachęcam do lektury kolejnego odcinka z serii DDD krok po kroku: Część IVa: Skalowalne systemy w kontekście DDD - architektura Command-query ResponsibilitySegregation (stos Write).

Przykładowe projekty oparte o: Spring, EJB i .NET można znaleźć pod tym adresem: http://code.google.com/p/ddd-cqrs-sample/.

DDD w Łodzi

W imieniu swoim jak i liderów Łódzkiego JUGa zapraszam w najbliższy wtorek (4 września) o godzinie 18:30 na prezentację poświęconą Domain Driven Design.

Prezentacja będzie dosyć ogólna i nie jest związana ściśle z Javą, tak więc zapraszamy entuzjastów różnych technologii.

Strona wydarzenia
Dyskusja na grupie Łódzkiego JUG

//===============================

Prezentacja dostępna na prezi.com.
Prezentacja będzie koncepcyjnym rozwinięciem technik, o których mówiłem goszcząc w Łodzi ostatnim razem: Przewodnik strukturyzacji architektury systemu. 10,5 klasycznych technik programistycznych leżących u podstaw nowoczesnej inżynierii oprogramowania

Implementing Domain-Driven Design

Dziś ukazała się elektryczna wersja najnowszej książki autorstwa Vaughna Vernona poświęconej praktycznym aspektom implementacji DDD: "Implementing Domain-Driven Design", którą możecie zakupić na safari books online.

Recenzję opublikuję zaraz po tym jak skończę ją czytać (ale w kolejce priorytetowej znajduje się ok 10 pozycji "miękkich").

Już teraz mogę napisać, że mając wcześniej dostęp do pewnych jej części, śmiało mogę polecić nawet zaawansowanym praktykom DDD.


//====================================

Nieskromnie dodam (po przejrzeniu spisu treści), że książka stworzona pod nadzorem elity współczesnej inżynierii oprogramowania (M. Fowler, E. Evans, G. Young, U. Dahan) tylko nieznacznie wychodzi merytoryką poza nasz projekt DDD-CqRS Leaven:]