O modelowaniu domeny

Z 25. O modelu i modelowaniu ze Sławkiem Sobótką

• nie ciśnij za mocno eksperta domenowego. Jak widzisz, że gdzieś już wychodzisz poza jego obszary kompetencji, to umów się z innym,
• często smoki tkwią w szczegółach, w jakiś dziwnych helperach, które rozmywają odpowiedzialności,
• nie zadawaj nieistotnych pytań. Jeśli coś ma szansę stać się np. raz na rok i potencjalna szkoda to 500zł to rzuć błędem, niech to gdzieś sobie tam sobie leży w logach, "nie pytasz prawdziwej wróżki ze złotą kulą o jakieś ekstremalne corner case'y"
• "stara szkoła modelowania" zakładała monolit, który obsługiwał über classy - User był zawsze i wszędzie tym samym userem. Nowoczesne podejście jest bardziej kontekstowe. User to nie to samo co płatnik, płatnik to nie to samo co subskrybent,
• ważne jest znajdowanie punktów swobodnych aka przecięć. Nie jest ważne czy ładujemy hulajnogę czy rower elektryczny. Ważny jest interfejs.
• biznesy cały czas się rozwijają i ewoluują. Core domain jakiegoś biznesu musiało być unikatowe, dobre w swojej klasie. Ale po jakimś czasie inne firmy mogły dogonić ten biznes i również mieć te funkcjonalności. Core przestał być corem, mógł zostać zepchnięty do domeny pomocniczej, lub nawet generycznej. "Wartość kina nie tkwi w dobrym systemie fakturowania"
• GUI często niesłusznie, mylnie pokazuje domeny. Podpinam coś do ładowarki i widzę co mi się ładuje. Ale po co? Jaką wartość do kosztu tu jest? Zreszta GUI powinno być w stanie posklejać info jak potrzebuje "encja na twarz i pchasz"
• waterfall to metoda "push." Analityk biznesowy pcha do analityka systemowego, systemowy do jakiegoś architekta, ten do leadów, leady do dev ... To generuje "odpady" (to co analityk systemowy nie zrozumie, to często odrzuci, tak samo lead od architekta). DDD to pull. Mam ogólny zarys co chce osiągnąć i dopytuje biznes tylko o to co potrzebuje. MODELARZ MUSI BYĆ TECHNICZNY, MUSI WIEDZIEĆ KIEDY WIEDZY JEST WYSTARCZAJĄCO.
• czasami rysowanie pozwala lepiej wyrazić input (proszę kogoś by mi narysował jak coś rozumie), a czasami output (układam sobie w głowie jak coś rozumiem)
• przez słuchanie przyswajamy wiedzę sekwencyjnie (słowo po słowie). Przez rysowanie jesteśmy w stanie trochę ten proces zrównoleglić.
• W systemach legacy występuje złożoność esencjonalna (od strony biznesowej jest coś skomplikowane) i złożoność przypadkowa (dodana przez deweloperów, poprzez dług technologiczny)