Niedawno natknąłem się na StackOverflow interesujące pytanie dotyczące Domain-Driven Design. Chciałbym się z Wami podzielić moimi przemyśleniami. Pytanie dotyczyło zaprojektowania logiki biznesowej dla domeny składającej się z trzech obiektów: Książki (Book), Rozdziału (Chapter) oraz Strony (Page): Problem polega na tym, który element, z przedstawionych trzech, powinien być korzeniem agregatu?

Autor: Z ogromną przyjemnością śpieszę donieść, iż projekt DDDSample.Net - .NET-owy klon projektu DDDSample - właśnie doczekał się pierwszej wersji. Wraz z projektem powstał także stosowny blog, na którym publikowane będą informacje dotyczące postępu prac oraz posty komentujące decyzje projektowe, które zostały podjęte przez autorów Java-owego oryginału.

Dzisiejszy post jest sponsorowany przez hipotetyczną hurtownię, której właściciele chcą zbudować system zarządzania towarami w oparciu o metodykę DDD. Skrócony opis domeny biznesowej przedstawia się następująco. Hurtownia ma na stanie wiele produktów. Każdy produkt ma określoną ilość, która znajduje się w magazynie. Ilość ta jest określona w jednostce miary danego produktu. Produkty mogą być zamawiane (pewna ilość produktu jest tymczasowo przypisywana d...

Na wstępie chciałbym zaznaczyć, że w żadnym razie nie jestem ekspertem od DDD. Ja się wciąż i dopiero uczę i moje posty z serii "Mentoring DDD" są wyrazami tegoż procesu (samo)kształcenia. Dlaczego więc "mentoring"? Ano dlatego, że wspieram Domain Driven Design w mojej firmie poprzez konsultacje, pomoc duchową i cielesną. Staram się przewidywać problemyi zdobywać wiedzę na temat sposobów ich rozwiązania zanim się pojawią. Nie posiadam jednak (jeszcze) tej wiedzy w postaci przetworzonej w trwałe połączeni...

Postanowiłem rozpocząć serię krótkich notek dotyczących Domain Drvien Design. Prosto z "pola bitwy", ponieważ mam to szczęście być architektem w projekcie, w którym wykorzystujemy DDD jako sposób projektowania poszczególnych modułów. Uparłem się na to DDD, to teraz mam.