Byznes zmienny jest,

wielu tego doświadczyło, ja też. Jako, że w torfowisku mam rozdwojenie jaźni, uznałem, żeby zdenerwować tego drugiego zrobię zmiany w event stormingu design level.

Dotychczasowy proces wyglądał tak (już jest nie aktualny) część pierwsza.

Wersja nowa wygląda tak jak poniżej

Można definiować rabaty według dwóch „kontekstów”. Jeden to są rabaty dla klientów a drugi dla reklamacji, różnią się parametrami takimi jak ilość oraz czas trwania oraz wykorzystaniem, pierwsze rabaty są przekazywane klientom a drugie tylko do reklamacji. Trzeciej opcji nie daje, nie chcę komplikować.

Tu zresztą będę już potrzebował stworzyć warstwę porozumiewania się między boudend contextami. Bedę mógł zastosować w praktyce to co przeczytałem w książce o DDD Erica Evansa na temat łączenia BC.

Potrzebuje informacji na temat klientów oraz reklamacji.

To było wczoraj dziś nastąpiła zmiana w założeniach, zaczołem kodować i coś tu  nie gra?!

Nastąpiła zmiana w  domenie generowania rabatów, byznes uznał, że jest błąd w logice, dlaczego? Chcemy generować kody rabatowe, a nie znamy ich ilości, mamy definicje i tam jest ilość, wykorzystajmy to.

Na początek przypisuje kod do definicji, spełniając warunek, że muszę mieć ilość nadaną, definicja nie musi mieć daty zakończenia ale może mieć, ta informacja nie jest istotna. Warunek „must be” to ilość kodów rabatowych.

Gdy mam już połączoną definicje z kodem to mogę wysłać zlecenie generowania. Pytanie jeszcze pozostaje jak to mogę przedstawić jeżeli mam sto kodów, tzn. że będę miał sto wpisów w bazie? Byznes nie zdradził tego jeszcze. Na tę chwile to nie jest istotne.

Wersja na dzień dzisiejszy traktowana jako ostateczna (dzień dzisiejszy). Wydzieliłem generowanie kodów do osobnej sub-domeny „Generowanie kodów”, resztę pozostawiłem w domenie „przygotowanie kodów”.

 

Teraz kod

Sub-domena przygotowanie kodów rabatowych.

Jak wcześniej wspominałem podzieliłem generowanie kodów na kody wysyłane do klientów, które to kody wymagają wygenerowania „jakiegoś” unikalnego ciągu znaków, mają określoną ilość oraz na kody, które  nie mają określonej ilości i mają nieunikalną nazwę.

Klasa reprezentowana przez tę sub-domenę nazywa się „RebateCode” .

Testy

Testy sprawdzają również warunek z datą, za pierwszym podejściem była ta reguła naniesiona na ES ale potem z niej zrezygnowałem uznając, że nie jest to warunek który musi być i jest to warunek opcjonalny czyli nie zawsze musi być spełniony (taki warunek można by jakoś zaznaczyć na ES). Najważniejsza jest ilość. Deklaracje: