Na czym operować mają serwisy w architekturze cebulkowej

0

Hej,
na potrzeby posta załóżmy poniższą strukturę projektu

  • Project.Core
    -- Domain
    -- Enums
    -- Repositories ( kontrakty )
  • Project.Infrastructure
    -- DAO
    -- DTO
    -- Migrations
    -- Querries
    -- Repositories ( implementacje )
  • Project.Services
    -- Exceptions
    -- Middleware
    -- Service Classes ....
  • Project.WebAPI
    -- Controllers

Zapewne przesadziłem z Repositories "raczej chyba na pewno" :) winno być jakiś DAL ale nie o to tutaj chodzi.
Moje pytania:

  1. Czy obiekty dto powinny znaleźć się w warstwie niżej niż przedstawiono?
  2. Czy kontrakty serwisów powinny znaleźć się w Infrastrukturze (przy założeniu, że w ogóle robimy interfejsy)?
  3. Czy Serwisy mają operować na obiektach domenowych czy na dto a mapowanie odbywa się w kontrolerach?
    na SO m.in. The same Martin Fowler says, that using DTOs between layers is overkill and make things too complicated. Why don't you simply use domain models and delegate the mapping to DTOs to the controller? Basically, is the only component that really uses DTOs as response model
  4. Gdzie umieścić np. AutoMapper klasę mapującą?
0

ad 3) to zalezy czy pytasz o application service czy domain service
ad 1) osobiscie dtosy umieszczam w warstwie (web) Api ktora jest de fakto warstwa widoku, spotkalem sie tez z nazewnictwem Boundary bo nie zawsze to jest web api (co jezeli jest np. Kafka) a nazywanie tego View zwykle zle kojarzy sie backendowcom ale nawet w ksiazce Evansa ta najwyzsza warstwa nazywa sie View
ad 4) w projektach ktore do tej pory widzialem mappery (nazywane tez factory) byly w tej samej warstwie co dtosy czyli API

1
john_doe napisał(a):
  1. Czy obiekty dto powinny znaleźć się w warstwie niżej niż przedstawiono?

A do czego te DTO służą?
Jeśli do komunikacji z zewnętrznymi API, to DTO od danego API powinny być w katalogach związanych z API. Czyli np. w Infrastructure masz:

  • NbpApiClient - i tam klasę klienta i jego DTO;
  • SendGridApiClient - i tam klasę klienta i jego DTO;
  • itd.

2. Czy kontrakty serwisów powinny znaleźć się w Infrastrukturze (przy założeniu, że w ogóle robimy interfejsy)?

A skąd one będą wywoływane? Jeśli z WebAPI to raczej nie, bo to by znaczyło, że musiałoby mieć dostęp do Infrastructure.

3. Czy Serwisy mają operować na obiektach domenowych czy na dto a mapowanie odbywa się w kontrolerach?

Mapowanie na obiekty domenowe na pewno nie w kontrolerach. Można dywagować, czy kontrakty aplikacji wystawiać jako kontrakty API czy nie, ale domena jako zależność API jawi się dziwna.

4. Gdzie umieścić np. AutoMapper klasę mapującą?

W każdej warstwie, w której chcesz mapować AutoMapperem.

Ta cała struktura jest w ogóle jakaś dziwna. Po co katalogi Enums i Exceptions? Rzeczy powinno dzielić się wg funkcjonalności, a nie wrzucać do worków na wszystko.

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