🔗 Kurs "Domain-Driven Design: Pragmatycznie" znajdziecie tutaj: https://domain-driven-design.net
💻 Link do repo najnowszego kursu: https://domain-driven-design.net/repo
✍ Link do boarda naszego kursu: https://domain-driven-design.net/miro
Potrzebowaliśmy trochę kontekstu (patrz poprzedni materiał), by móc w końcu przedstawić Wam chyba najmniej zrozumiany wzorzec taktycznego DDD - agregat.
🛒 W tym materiale kontynuujemy naszą pracę nad domeną znanego, polskiego sklepu z elektroniką użytkową i mierzymy się z najtrudniejszym z trzech wymagań, które sobie postawiliśmy.
💡 Dowiecie się jak radzić sobie z wymaganiami, które rozciągają się na większą liczbę obiektów i zawierają w sobie aspekt czasu. Zobaczycie oczywiście zarówno te lepsze jak i gorsze rozwiązania wraz z naszym komentarzem (z którym możecie się ofc nie zgadzać 😉).
👨💻 Tak jak poprzednio, kolejne iteracje rozwiązywanego przez nas problemu znajdziecie na naszym GitHubie: https://github.com/devmentors/ddd-building-a-model
⏱ TIMECODES:
00:00:00 Intro
00:00:16 Wstęp i przypomnienie dziedziny problemowej
00:02:33 Dlaczego agregat to błędnie rozumiany wzorzec?
00:07:09 Agregat jako graf obiektów bez kontekstu problemu
00:15:39 Enkapsulacja agregatu, publiczne API i Hyrum's Law
00:20:31 Zawężenie granic agregatu - aspekt czasu
00:26:07 Czym faktycznie jest agregat?
00:35:25 Nadmiarne zawężenie granic agregatu - problem zapisu dwóch agregatów na raz
00:43:04 Reguły spójne natychmiast - ale czy na pewno?
00:58:40 Kurs Domain-Driven Design - czego możecie się spodziewać + presale
01:04:55 Podsumowanie
Zapraszamy również na:
⚡️ Discord: https://devmentors.io/discord-pl
⚡️ Instagram: https://www.instagram.com/devmentors_pl
⚡️ TikTok: https://www.tiktok.com/@devmentors
⚡️ Twitter: https://twitter.com/dev_mentors_pl
#domaindrivendesign
#programowanie
#programming
#ddd
#refactoring
#architektura
#software
#dotnet #java #javascript #python #php #ruby #rust #golang