Logiczny podział aplikacji na warstwy -> Core, Infrastructure, Api

0

Mam kilka pytań odnośnie projektowania aplikacji na warstwy :)

Core: Entities/Domain, IRepositories
Infrastructure: Repositories, IServices, Services
Api: Controllers

  1. Czy taka struktura aplikacji jest zaprojektowana w przejrzysty sposób?
  2. IServices, Services powinny być w jednej warstwie?
  3. Czym jest Use Cases? to samo co Commands?
  4. Use Cases, Commands, Handlers, DTO mogą być w warstwie Infrastructure?
  5. Podejście DTO jest dobre? zawsze powinno się projektować aplikacje z obiektami DTO?
0

Nie masz czasem tego na odwrót? Core powinno zawierać kontrakty (interfejsy) repozytoriów, a infrastruktura ich implementacje.

0

Czym jest Use Cases? to samo co Commands?

Use case to raczej termin biznesowy a nie coś co masz w kodzie.

Use Cases, Commands, Handlers, DTO mogą być w warstwie Infrastructure?

Commands i handlers wykonujace jakąś logikę biznesową powinny być w Core. Po to właśnie masz abstrakcje żeby handler mógł operować na interfejsach a nie konkretnej implementacji. Warstwa infrastruktury dostarcza te implementacje. Poczytaj sobie o "dependency injection" oraz "programming to an interface".

Podejście DTO jest dobre? zawsze powinno się projektować aplikacje z obiektami DTO?

Jeśli masz sytuację gdzie DTO się przyda (np. w komunikacji klient - > serwer) to tak.

0

Nie wiem jak w .Net, ale w Javie jeśli Services zawierają logikę biznesową to powinny być w Core.
Jeśli logikę biznesową masz już w Entities to Services zawierają tylko logikę biznesowę która operuje na dwóch różnacy klasach Entities i nie wiadomo do której bardziej pasuje ta logika.

W DDD książce "DDD dla architektów oprogramowania". podział na warstwy jest taki:

  1. warstwa - API Warstwa UI - kontrolery i prezentery HTML, wystawiane api synchroniczne (REST, SOAP, Avro, Protocol Buffer), wystawiane api asynchroniczne (AMQP, RabbitMQ, Kafka).
  2. warstwa - Logika Aplikacji Warstwa Aplikacji - (teoretycznie cieńka), logowanie wyjście wejście, zarządzanie transakcjami, autoryzacja i inne nieciekawe rzeczy .
  3. warstwa - Logika Biznesowa czyli Domena lub Core Warstwa Domeny - grube Encje (zawierające logike biznesową), Servisy (zawierające logikę biznesową), interfejsy wszystkiego co zostanie zaimplementowane w warstwie czwartej i jest potrzebne w warstwie trzeciej.
  4. warstwa - Infrastruktura Warstwa Infrastruktury - Implementacja interfejsów potrzebnych do komunikacji ze światem zewnętrznym czyli Repozytoria, Klienty synchroniczne (REST, SOAP, Avro, Protocol Buffer), Klienty asynchroniczne (AMQP, RabbitMQ, Kafka).

Ogólnie Core nie powinien wiedzieć nic o bazie danych, serializacji, prezentacji i komunikacji ze swiatem zewnętrzny.
I najlepiej by było gdyby byłą możliwość skompilowania Core'a niezależnie od reszty projektu.

1

Pisząc o serwisach miałem na myśli serwisy bardziej związane z infrastrukturą, np. wysyłanie maili. Swoją drogą warstwy o których mowa i o których sam piszesz nie mają zbyt wiele wspólnego z DDD. To prostu N-Layered Architecture a nie żadne DDD. Nastała jakaś moda nazywania wszystkiego DDD tam gdzie mamy ładny podział odpowiedzialności?

0
Aventus napisał(a):

Pisząc o serwisach miałem na myśli serwisy bardziej związane z infrastrukturą, np. wysyłanie maili. Swoją drogą warstwy o których mowa i o których sam piszesz nie mają zbyt wiele wspólnego z DDD. To prostu N-Layered Architecture a nie żadne DDD. Nastała jakaś moda nazywania wszystkiego DDD tam gdzie mamy ładny podział odpowiedzialności?

Może nie ma nic wspólnego, ale jest w książce "DDD dla architektów oprogramowania". W rozdziale 4. Architektura, w podrozdziale Zasada odwracania zależności.

Niestety nie wiem kto wymyślił architekturę czterowarstwową i zaczął ją promować w tej postaci (Warstwa UI, Warstwa Aplikacji, Warstwa Domeny, Warstwa Infrastruktury), ale bardzo chętnie bym się dowiedział jeśli Ty wiesz.

0

Ok niech będzie, ale autor z pewnością nie chce pisać aplikacji opartej o DDD. Same warstwy nie są czymś typowym dla DDD a jest wręcz na odwrót- DDD zapożycza idee N-Layered Architecture (lub też hexagonal, fundamentalnie są podobne).

0

Widzę, że strasznie dużo tych podejść/wzorców do projektowania aplikacji :D
Chce coś przejrzystego, ale z uwzględnieniem: commands i events. Taki 3-warstwowy podział aplikacji (Core, Infrastrukture i API) wydaje mi się najbardziej czytelny, ale teraz już nie wiem jak zaprojektować swoją aplikacje w poprawny sposób... może coś zaproponujecie? albo polecicie jakieś materiały/książki (pod asp.net)?

Co myślicie o takim wzorcu?

onion architecture:
Api - contains MVC, controllers, appsettings (saparated from Core)
Core - center of onion with Domain classes
Infrastructure - contains all business logic e.g. services, handlers, mappers, repositories, extensions

struktura zaczerpnięta z tego artykułu:
https://www.wojciechseweryn.pl/2018/04/07/plaska-deska-warstwa-prezentacji-dto-automapper/

tutaj przykład projektu o takiej strukturze:
https://github.com/WoSew/Passenger

1

Trochę pokręcone. Logika biznesowa to nie infrastuktura, to Core aplikacji. Ogólnie trzeba umieć rozdzielić logikę biznesową od logiki infrastruktury. Polecam książkę Czysta Arkitektura

1

Ta cytowana definicja jest błędna. Wystarczy zobaczyć pierwszy lepszy diagram Onion Architecture w Google- zarówno modele jak i logika biznesowa należą do Core. Swoją drogą ja bym tutaj za bardzo nie przesadzał. Jak chcesz napisać relatywnie prostą aplikację z ładnym podziałem to zwykłe warstwy Core, Infrastructure, Application (w tym UI) wystarczą. Jeśli w trakcie pisania okaże się że to nie wystarczy to możesz dokonać modyfikacji.

Tutaj jest fajnie i prosto to przedstawione: https://github.com/dotnet-architecture/eShopOnWeb

0
Aventus napisał(a):

Ta cytowana definicja jest błędna. Wystarczy zobaczyć pierwszy lepszy diagram Onion Architecture w Google- zarówno modele jak i logika biznesowa należą do Core. Swoją drogą ja bym tutaj za bardzo nie przesadzał. Jak chcesz napisać relatywnie prostą aplikację z ładnym podziałem to zwykłe warstwy Core, Infrastructure, Application (w tym UI) wystarczą. Jeśli w trakcie pisania okaże się że to nie wystarczy to możesz dokonać modyfikacji.

Tutaj jest fajnie i prosto to przedstawione: https://github.com/dotnet-architecture/eShopOnWeb

Dzięki za linka. O to mi chodziło :)
Czyli w Core są Entities, Interfejsy, własne wyjątki, jakieś filtry
Natomiast w warstwie Infrastructure: implementacje interefejsów z warstwy Core, pliki konfiguracyjne - połączenie z bazą danych

  1. Czy klasa konfiguracyjna dla mappera powinna być w Infrastructure?
  2. Obiekty Dto umieścić w Core czy Infrastructure?
  3. IHandlers, ICommands, IEvents umieścić w Core, tak? ale co z ich implementacją? również w warstwie Core czy jednak Infrastructure?
1

Ja DTO wywalam do jakiegoś Shared/Common czy jak to tam ludzie nazywają, bo potrzebuje ich na froncie, a przecież nie będę 2 razy definiować tych samych klas.

0
bezikan napisał(a):
  1. Czy klasa konfiguracyjna dla mappera powinna być w Infrastructure?

To chyba zalezy. Jesli mapujesz cos tylko w warstwie aplikacji to rownie dobrze mozesz to umiescic tam.

  1. Obiekty Dto umieścić w Core czy Infrastructure?

Tak jak napisal @WeiXiao, leppiej miec to w jakiejs wspolnej warstwie. Podzial na np. Core/Infrastructure/Application nie oznacza ze nie mozesz miec wiecej projektow.

  1. IHandlers, ICommands, IEvents umieścić w Core, tak? ale co z ich implementacją? również w warstwie Core czy jednak Infrastructure?

Implementacja to logika biznesowa. Jesli masz np. ConfirmOrderCommandHandler to umiescisz go tam gdzie reszta logiki biznesowej. To co bedzie dostarczac infrastruktura to np. implementacja serwisu odpowiedzialnego za wysylanie maila lub implementacja dto/repozytorium. Sadzac po tym co piszesz za duzo rzeczy chcesz upychac w warstwie infrastruktury.

1 użytkowników online, w tym zalogowanych: 0, gości: 1