Czym zajmuje się programista? Pisaniem kodu, konfiguracją środowisk, debugowaniem, integracją z zewnętrznymi systemami? Z pewnością, ale czy jest to istota jego pracy?

Polityka to Building Block z DDD, który pozwala otwierać model na rozbudowę w tych miejscach, w których biznes może tego faktycznie potrzebować. Pojedyncze Polityki zwykle są stosunkowo proste, ich kompozycja może jednak modelować bardzo złożone wymagania biznesowe. Jak zaimplementować je w C#, żeby maksymalnie zwiększy czytelność?

Projekty i namespace’y to niedoceniane elementy, które mogą znacząco poprawić czytelność naszego kodu. Warto stosować je w sposób przemyślany, a nie „jakkolwiek, bo to przecież nieistotne”. Kod czyta się co najmniej 10 razy częściej, niż się go modyfikuje. Warto więc zainwestować w jego czytelność i wymusić na poziomie kompilacji tak wiele sprawdzeń jak to tylko możliwe.

Na poziomie aplikacji architektura powinna wspierać modelowanie domeny czyli serca całego systemu. Czym powinna się charakteryzować architektura, żeby wspierać podejście Domain First? Czy tradycyjne warstwy są dobrą odpowiedzią na te potrzeby?

Dobra architektura kojarzy się zwykle z bardzo dużym wysiłkiem przy starcie projektu. Czy jednak musi tak być? Czy nie da się tego zrobić lekko i rozwijać architektury wraz z rozwojem potrzeb projektu? Co tak naprawdę sprawia, że architektura kojarzy się z ogromem pracy? Warto odpowiedzieć sobie na te pytania, bo system nie może nie mieć architektury.

Persystencja zawsze budzi wiele emocji i skrajnych opinii. W tym artykule pokażemy, jakie opcje są do wyboru przy persystowaniu agregatów z DDD i jak pragmatycznie do nich podejść. Przejdziemy kolejno przez bezpośredni zapis agregatów, robienie Snapshotów, tworzenie osobnego modelu danych na podstawie zdarzeń, a na koniec dotrzemy do Event Sourcingu.