Nie wiem o co chodziło wykładowcy, ale z mojego doświadczenia z wykładowcami wynika, że im czasem o nic nie chodzi: Wzorce projektowe klasy CASE
Być może rację ma @AreQrm, że chodziło o Anemic Domain Model, który jest antywzorcem. Tylko nie każda aplikacja ma zaawansowaną logikę, którą trzeba w DDD upychać. Większość aplikacji to CRUD, w który nie ma prawie żadnej logiki, więc i klasa, która ma same pola, bez zachowania nie jest niczym złym.
@insectoman, piszesz, że Ty właśnie masz anemiczne encje i całość logiki w serwisie - to się nazywa transaction script
i takie podejście może być dobre albo i nie, w zależności od przypadku. Moim zdaniem w przypadku prostej logiki nie ma co na siłę upychać jej w encjach i utrudniać sobie życie przez DDD, bo to spowoduje więcej problemów niż pożytku. Generalnie jestem zdania, że lepiej wyjść od takiej architektury jak Twoja, a później ewentualnie refaktoryzować w stronę DDD, i to tylko w tych elementach systemu, w których faktycznie jest potrzeba.
Drugi często zapominany fakt, to to, że model domeny i model składowania danych, to nie jest to samo. A więc encje mogą mieć dane i logikę na nich operującą, ale w warstwie DAL te encje mogą być konwertowane na właśnie takie struktury danych bez metod. Jak rozumiem Java wymaga do takiego tworu adnotacji @Entity
, mimo że faktycznie nie będzie encją (ani nawet obiektem), no ale to już jest konwencja technologii i nic z tym nie zrobimy. (Mnie też wkurza, że NHibernate stosuje wszędzie nazwę Entity, mimo że encji żadnych nie mam.)
@azalut, zgodnie z DDD, serwisy są po to, aby realizować operacje, które wymagają kilku encji. Np. przypisanie losowym klientom losowych faktur. To nie pasuje ani do Order
ani do Invoice
, prawda?
Co do niemutowalności i OOP - celem niemutowalności jest to, aby nic przypadkiem nie zepsuło obiektu. W OOP do tego służy enkapsulacja. Dopóki stan utworzonego obiektu potrafi zmieniać tylko on sam, dopóty nie ma dużego niebezpieczeństwa. W tym celu, np. klasa Order
powinna mieć oddzielne metody zmieniającą status zamówienia (np. confirm()
, send()
, finish()
) zamiast publicznej setStatus(StatusEnum newStatus)
, którą każdy może zepsuć stan obiektu.
A jeśli chcemy mieć pełną niemutowalność, to metody confirm()
i tak dalej mogą zwracać nam nowy Order
ze zmienioną wartością pola... Ale czy to ma sens? Wątpliwe.
Tak przy okazji - DDD to tak naprawdę buzzword, mądrzejsza nazwa dla OOP. Gdyby ludzie trzymali się abstrakcji i enkapsulacji, to żadnego DDD nie trzeba byłoby wymyślać. :)