@eziomou:
No i tu pojawia się problem pt DDD + JPA. Powiem szczerze, na samym DDD średnio się znam ale występuje problem mieszania logiki biznesowej z frameworkiem i do tego tak "cięzkim" jak JPA. Dodatkowo taki styl narzuca mutowalność, a mutowalność w logice biznesowej na ogół jest zła. Rozumiem mutowalny stan np. socketa, okienka w Swingu (choć akurat w Javie GUI się już za bardzo nie pisze) ale moim zdaniem od czegoś takiego jak
book.reserve() {
book.reserveDate = LocalDateTime.now(clock);
}
lepsze jest
book.reserve() {
return book.withReserveDate(LocalDateTime.now(clock))
}
Obiekty które reprezentuję domenę/logikę biznesową powinny być niemutowalne, i własnie dlatego nie lubie klasycznego podejścia do DDD. Wydaje mi się że rozwiązaniem moich problemów jest architektura hexagonalna :D
Dziękuje za wypowiedź i przejrzenie kodu.
Mógłbyś dokładnie napisać w którym miejscu w kodzie występuje mieszanie logiki biznesowej z frameworkiem oraz szersze uzasadnienie reguły, że obiekty logiki biznesowej powinny być niezmienne?
Książka zaprojektowana jest w ten sposób, dlatego że reprezentuje fizyczną kopie książki występującej w magazynie, jej tożsamość ma znaczenie. Dwie książki o dokładnie tych samych atrybutach ciągle będą innymi książkami, a o ich tożsamości decyduje jedynie identyfikator (w moim przypadku id jest identifykatorem biznesowym). Podobnie jak dwie osoby o tych samych imionach i nazwiskach są ciągle innymi osobami, mają swoją tożsamość oraz ciągłość w czasie.
Gdyby książka była obiektem niezmiennym, w danym momencie działania programu mógłbym mieć dowolną ilość kopii tej samej książki (pod względem tożsamości) o zupełnie innych stanach. Tutaj mógłby wystąpić problem ze stwierdzeniem, która z kopii posiada aktualny stan.
W podejściu DDD stosuje się obiekty niezmienne tzw. Value Object
dla obiektów domeny, których tożsamość nie ma znaczenia. Jako przykład mogą posłużyć pięniądze, w większości przypadków nie ma znaczenia tożsamość dwóch obiektów pieniędzy o tej samej wartości, tutaj jak najbardziej mają zastosowanie obiekty niezmienne.
Dodatkowo, wyobraź sobie, że rzeczywiście wszystkie obiekty domeny są niezmienne i akurat tak się zdarzyło, że mamy kilka bardzo ciężkich obietów tzn. takich które mają wiele asocjacji i na każdym z tych obiektów wykonujemy bardzo dużo operacji. W takim przypadku przy każdej operacji tworzona jest głęboka kopia całego drzewa obiektów i być może przez pomyłkę przechowywana gdzieś w pamięci. Byłbym wdzięczny gdbyś uzasadnił stwierdznie, że zmienność obiektów logiki biznesowej jest zła.