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 właściwie jest subdomena? W myśl definicji, subdomena jest zazwyczaj 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 właściwie czemu to ma służyć? Jeśli 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