Domain-Driven Design jest skuteczną metodą analizy i modelowania złożonych, nierozpoznanych jeszcze problemów biznesowych. Jednak niektóre wzorce strategiczne są bardzo mgliste i mogą nie dostarczać konkretnych sposobów do działania w projekcie. Krytyka DDD w tym obszarze wydaje się mieć sporo podstaw...
Bo czym adekwatnie jest subdomena? W myśl definicji, subdomena jest zwykle wyodrębnionym obszarem, który może być zarządzany i rozwijany niezależnie od innych, posiadając swoje specyficzne reguły biznesowe, modele i zasoby. Ale czym się subdomena różni od domeny, jak skutecznie wyznaczyć ten "wyodrębiony" obszar i adekwatnie czemu to ma służyć? jeżeli dodamy to tego lingwistyczne granice kontekstów, to robi się z tego trudna do strawienia mieszanka.
Dziś zapraszam na rozmowę z Łukaszem Szydło, w której dotykamy tematyki modularyzacji systemu w oparciu o inne, prostsze narzędzia. Na koniec dnia zajmujemy się wprowadzaniem zmian, więc zmodularyzujmy system tak, aby było nam je łatwo wprowadzać.
W tym odcinku rozmawiamy z Łukaszem o:
- hype na Domain-Driven Design i trudnościach w jego stosowaniu
- intuicjach, heurystykach vs. praktyki inżynieryjne
- analizie domeny na mniejsze części, poprzez odkrywanie niezależnie zmieniających się w niej rzeczy
- sumulacji zmian i wykorzystaniu atrybutów jakościowych w procesie dekompozycji
- stabilnych granicach aplikowalności modelu, wynikających z wprowadzanych zmian
- weryfikacji wytwarzanych w ten sposób podziałów w projekcie
- dobrych momentach na refaktoryzację systemu
Materiały dodatkowe:
- Wspomniana w odcinku prezentacja Real Software Engineering Glenna Vanderburga, VP of Engineering w First
- SDLab, inicjatywa projektów badawczych w zakresie projektowania oprogramowania
