[E.....r]

Ostatnio zainteresowałem się DDD oraz CQRS i postanowiłem spróbować zastosować te rozwiązania do prostej, crudowej apki typu to-do list.
W pakiecie core mam: klasę Task, która reprezentuje zadanie do zrobienia, 2 interfejsy repozytorium - jeden TaskQueryRepository (metody getAll i getById) i drugi TaskCommandRepository (metody add, update i delete) oraz 2 serwisy jeden TaskQueryService i drugi TaskCommandService, korzystające z adekwatnych repo.
W pakiecie framework mam springowe rest api rozbite na 2 controllery TaskQueryApi i TaskCommandApi.
I tutaj zaczynają się schodzić. Zgodnie z zasadami czystej architektury chciałem, żeby apka była jak w najmniejszym stopniu zależna od frameworka, dlatego zrezygnowałem ze springowego kontenera IoC (oglądałem trochę konferencji @jarekr000000) i w tych controllerach zainicjowałem wszystko przez "new".Przy inicjowaniu serwisów pojawia się problem z repo Spring Data JPA. Spring sam sobie go tworzy i nie udostępnia tej klasy, przez co nie mogę sam stworzyć nowego obiektu. Rozwiązaniem okazał się Hibernatem, ale chciałbym korzystać jednak ze Spring Data JPA albo czegoś podobnego. Co o tym wszystkim sądzicie?
#java #naukaprogramowania #programowanie

[C.....y]

postanowiłem spróbować zastosować te rozwiązania do prostej, crudowej apki typu to-do list

@Edelner: tu najprawdopodobniej popełniłeś naprawdę wielki błąd. Nie wiem też, jak to wygląda w Javce (.NET here), ale nie wiem, czemu miałbyś nie zastosować kontenera IoC na poziomie samej aplikacji springowej - to domena ma być wolna od jakiejkolwiek infrastruktury, nie warstwy zewnętrzne w cebulce. Aplikacja korzystająca z tego siedzi przecież na zewnątrz cebulki w czystej architekturze

[E.....r]

@Czesiowcy: Problem jest taki, że u was w C# możecie mieć jakieś serwisy w innej warstwie i powiedzieć klasie konfiguracyjnej ASP.NET Cora, żeby je wstrzyknęła gdzieś a w Springu klasa musi być oznaczona annotacją np. @Service i przez to jeśli chcę kontener IoC to musze zrobić de facto kopię tej klasy serwisowej i dać jej tę annotację, bo przecież nie zrobię tego w corze, bo mi wpadnie framework do tej corowej

[C.....y]

@Edelner: Jeśli Cię to pocieszy, to częstym podejściem w .NET jest stosowanie samego EFa Core jako repozytorium i jednostek pracy, bez abstrakcji, i zarażanie tym domeny. Konfiguracja może sobie siedzieć gdzieś w persystencji, ale nawet bez przekazywania DbContextu do domeny to narzuca pewien kształt obiektów domenowych. IMHO straszny karakan powodujący masę problemów, ale zależy, jak bardzo chcesz być koszerny. Nawet sam MS pokazuje to w swoich tutkach do DDD. Ale generalnie

[KotoFan]

@Edelner: Pokaż ten kod może ;). Nie musisz rezygnować ze springa żeby mieć czyste domenowe klasy. Wszelkie adaptery na bazę danych, api itp możesz sobie zdefiniować jako interfejsy które w innej warstwie implementujesz.

[krasnoludkolo]

@Edelner: DDD jest do projektów gdzie jest bardzo skomplikowana domenta, todolist nie wygląda na taki ( ͡° ͜ʖ ͡°)

co do bazy danych to dawaj JOOQ/JDBI

[draxgar]

a w Springu klasa musi być oznaczona annotacją np. @Service i przez to jeśli chcę kontener IoC to musze zrobić de facto kopię tej klasy serwisowej i dać jej tę annotację, bo przecież nie zrobię tego w corze, bo mi wpadnie framework do tej corowej warstwy.

@Edelner: nie musi. Zostaw sobie IoC tylko w inny sposób:
W module w którym masz spring-a, tworzysz serwisy, Spring Data, wszystko co potrzebujesz by Ci

[E.....r]

@draxgar: Super, dzięki! Właśnie tego potrzebowałem.