Onion/Clean Architecture, a Entity Framework bez "repozytoriów" (DAO)

Jestem w trakcie robienia projektu do CV. Chcę wykorzystać wzorzec czystej architektury.
Aplikacja będzie polegała na zarządzaniu (CRUD) produktami, kategoriami produktów, zamówieniami.
Nie robię żadnego DDD. Przeczytałem na forum, żeby nie robić dodatkowej warstwy abstrakcji zwanej przez niektórych "repozytoriami" (DAO), ponieważ Entity Framework DbContext to UoW, natomiast DbSety to repozytoria.

Mam sobie taką strukturę projektów w solucji:

Gdybym chciał implementować "repozytoria" (DAO), to wrzuciłbym je pewnie do projektu Infrastructure.Persistence, a następnie przy pomocy DI wstrzykiwałbym je do serwisów, w których mam logikę biznesową. Jednak nie chcę tego robić - będę korzystał bezpośrednio z DbContextu/DbSetów.

1. Jak w takim razie rozdzielić logikę biznesową od operacji dostępu do danych (wywołań metod na DbContexcie)?
2. Czy modele mapowane przez ORM na tabele w bazie danych powinny znajdować się w projekcie Domain, jeżeli nie, to gdzie?
3. Czy logika biznesowa powinna znajdować się w projekcie Application?
4. Czy jest sens rozdzielenia projektu Core na projekty Application oraz Domain?
5. Czy mógłby mi ktoś wyjaśnić różnicę między logiką biznesowa, a logiką aplikacji (na przykładzie zarządzania produktami/zamówieniami)?

Czy modele mapowane przez ORM na tabele w bazie danych powinny znajdować się w projekcie Domain, jeżeli nie, to gdzie?

dlaczego twój "Core" miałby się interesować tym, jakie modele musisz mieć aby być w stanie zareprezentować dane dla danego kontenera na dane - bazka, plik, jakiś fancy cloudy

Czy mógłby mi ktoś wyjaśnić różnicę między logiką biznesowa, a logiką aplikacji (na przykładzie zarządzania produktami/zamówieniami)?

Logika biznesowa to ta, która m.in jest ustalana przez ekspertów domenowych np. jaki podatek na to i tamto, jaki wzór matematyczny na coś tam.

Logika aplikacji to np. że jak klikasz przycisk opcje, to otwiera się okno z opcjami.

Jak w takim razie rozdzielić logikę biznesową od operacji dostępu do danych (wywołań metod na DbContexcie)?

Moim zdaniem, pytanie jest jak bardzo chcesz się uniezależnić od "storage danych"

Jeżeli chcesz być bardzo elastyczny, no to pewnie najlepiej jakaś abstrakcja typu repo czy coś podobnego

Ale, jeżeli uważasz że wystarczy Ci Driver do EF Core oraz że właściwie ty nie zamierzasz zmieniać w przyszłości storage (a nawet jeśli, to EF i tak ma drivera do niego), to ja bym walił bezpośrednio DbContext.

Potrzebujesz jakieś abstrakcji dostępu do danych. Aplikacji nie powinno obchodzić skąd pobierane są dane, czy z bazy danych, czy z pliku tekstowego, czy wszystko zapisuje się w pamięci.
Repozytorium to nie to samo co dao. Repozytorium to kolekcja encji domenowych a dao to warstwa dostępu do danych, np. bazy SQL. Repozytorium może i często jest opartę na dao bazy danych. Repozytorium przyjmuję encję domenową i tłumaczy ją na encję bazodanową i ją zapisuje. Adekwatnie w przypadku pobierania encji. Repozytorium pobiera encję bazodanową przez dao i potem tłumaczy ją na encję domenową i ją zwraca.

1.Jak w takim razie rozdzielić logikę biznesową od operacji dostępu do danych (wywołań metod na DbContexcie)? >
2.Czy modele mapowane przez ORM na tabele w bazie danych powinny znajdować się w projekcie Domain, jeżeli nie, to gdzie?
3.Czy logika biznesowa powinna znajdować się w projekcie Application?
4.Czy jest sens rozdzielenia projektu Core na projekty Application oraz Domain?
5.Czy mógłby mi ktoś wyjaśnić różnicę między logiką biznesowa, a logiką aplikacji (na przykładzie zarządzania produktami/zamówieniami)?

1.Serwisy z logiką biznesową powinny mieć wstrzyknięte jakiś interfejs reprezentujący abstrakcję w dostępie do danych np. DomainNameRepository.
2.Nie, powinny znajdować się w warstwie infrastruktury. Domeny nie powinno obchodzić gdzie są zapisywane dane.
3.Logika biznesowa dotycząca domeny (jak ktoś wyżej napisał, np. obliczanie podatku) powinna być w warstwie domeny a np. crud w warstwie aplikacji.
4.Tak. W Domain masz model domenowy z jakąś logiką a w aplikacji np. cruda.
5.Logika biznesowa dotyczy domeny np. te już wyżej wspomniane wyliczanie podatku itp. a logika aplikacji to crud np.

Odpowiadając na zagadnienie z tytułu wątku to tak- jeśli chce się robić "czyste" onion architecture to siłą rzeczy nawet EF powinno być wyabstrahowane. To czy ta abstrakcja przybierze formę repozytorium czy czegoś innego to oddzielna kwestia, ale przede wszystkim chodzi o to że szczegóły takie jak ORM użyty do komunikacji z bazą są ukryte przed warstwą biznesową/domenową.

Jestem w trakcie robienia projektu do CV. Chcę wykorzystać wzorzec czystej architektury.
Aplikacja będzie polegała na zarządzaniu (CRUD) produktami, kategoriami produktów, zamówieniami.

No to bez sensu. Jak chcesz robić CRUD to nie potrzebujesz żadnej Clean Architectury. Może w takim razie wymyśl coś co będzie miało jakąś logikę biznesową?

Czy modele mapowane przez ORM na tabele w bazie danych powinny znajdować się w projekcie Domain, jeżeli nie, to gdzie?

W domain masz obiekty domenowe które nie wiedzą nic o warstwie perzystencji. Np. masz jakiś obiekt typu Issue z metodami assigneTo(UserId userId). Repozytoria mają interface w domenie, a implementacje w infrastrukturze.

Napisz co to jest wg Ciebie wzorzec czystej architektury i jak się on ma do Twojego projektu?

enx napisał(a):

1. Jak w takim razie rozdzielić logikę biznesową od operacji dostępu do danych (wywołań metod na DbContexcie)?

No w jakichś klasach innych niż serwisy aplikacyjne. Mogą to być encje domenowe albo jeszcze jakieś inne byty.
Tylko jaką właściwie logikę biznesową, skoro robisz CRUDa?

2. Czy modele mapowane przez ORM na tabele w bazie danych powinny znajdować się w projekcie Domain, jeżeli nie, to gdzie?

W Persistence, tam gdzie DbContext i DbSety.

3. Czy logika biznesowa powinna znajdować się w projekcie Application?

Jak sama nazwa wskazuje nie bardzo.

4. Czy jest sens rozdzielenia projektu Core na projekty Application oraz Domain?

Tak, albo nie, w zależności od tego, ile masz tego "Domain" w CRUDzie.

5. Czy mógłby mi ktoś wyjaśnić różnicę między logiką biznesowa, a logiką aplikacji (na przykładzie zarządzania produktami/zamówieniami)?

Warstwa aplikacji przyjmuje dane z warstwy prezentacji, i organizuje cały przepływ od walidacji, poprzez pobieranie danych, wykonanie jakichś obliczeń/operacji biznesowych, zapisanie danych, odesłanie wyniku. Oczywiście każda ta czynność jest gdzieś delegowana. A obliczenia/operacje biznesowe to logika biznesowa.

jarekr000000 napisał(a):

Napisz co to jest wg Ciebie wzorzec czystej architektury i jak się on ma do Twojego projektu?

@jarekr000000: ja wątpię, żeby coś w tym kontekście mogło być według kogokolwiek. Czysta architektura jest jedna: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html