Po co tworzyć serwisy domeny w serwisach aplikacji?

Witam, dopiero co poznaje sposób tworzenia oprogramowania opartego o DDD, więc proszę o wyrozumiałość. Czytam i oglądam różne tutoriale i spotkałem intrygujące mnie podejście. Mianowicie, tak jak w tytule serwisy domenowe zostały opakowane o dodatkowe serwisy aplikacji. Czyli dajmy na to:
Produkt serwisu domeny

 public class ProductService : Service<Product>, IProductService
    {
        private readonly IProductRepository _repository;

        public ProductService(IProductRepository repository)
            :base(repository)
        {
            this._repository = repository;
        }

        public IEnumerable<Product> FindByName(string name)
        {
            return _repository.FindByName(name);
        }
    }
 

Produkt serwisu aplikacji

 
 public class ProductService : Service<Product>, IProductService
    {
        private readonly IProductService _productService;

        public ProductService(IProductService productService)
            :base(productService)
        {
            this._repository = repository;
        }

        public IEnumerable<Product> FindByName(string name)
        {
            return _productService.FindByName(name);
        }
    }

Zastanawiam się dlaczego została zrobiona dodatkowa warstwa serwisów? Czy nie lepiej wywoływać w kontrolerach, metody serwisów domenowych? Wiem, że w DDD model dzielony jest na logikę biznesową i logikę aplikacji, tutaj częściowo zostało to zrealizowane tylko miałem pewność, że w serwis aplikacji będzie odgrywał inna rolę np. autoryzacje, zabezpieczania a nie korzystał z logi domeny? No chyba, że jest w tym jakiś ukryty sens, którego nie dostrzegam, tak więc prosiłbym o pomoc i dyskusje.

Pozdrawiam.

Controller => Service Layer => Repository

Wystarczy, że tak to będzie wyglądać. Wszelka logika w serwisach, z kontrolera wywołuje się metody z serwisu, które następnie działają już na repozytoriach.

Wydaje mi się, że to dlatego, że DDD nie używa się do trywialnych domen, a ten przykład na właśnie takiej operuje. Tutaj równie dobrze mógłbyś zastosować architekturę CRUD "Encje na twarz i pchasz" a nie opakowywać to w repo, serwis, serwis, kontroler itd. Zbędne warstwy abstrakcji. (Chyba, że to ułamek systemy w tej architekturze i jest zrobiony tylko po to by się wpasować, a ten ułamek tylko jest trywialny)
Ale to mają do siebie czasem przykłady, że są niedostosowane do warunków polowych bo mają być łatwe...

Rejencina napisał(a):

Zastanawiam się dlaczego została zrobiona dodatkowa warstwa serwisów? Czy nie lepiej wywoływać w kontrolerach, metody serwisów domenowych?

Nie.
Po pierwsze dlatego, że pojedyncza transakcja biznesowa często operacja wymaga użycia kilku serwisów domenowych. Serwis aplikacyjny pozwala taką transakcje opakować w jednej metodzie. Umieszczenie takiego kodu w kontrolerze byłoby zaś złamaniem MVC.
Po drugie dlatego, że to by było możliwe wyłącznie w aplikacji jednowarstwowej. Często zaś jest tak, że logika domenowa pracuje na innym serwerze niż web, więc potrzebna jest jakaś warstwa nad nią, aby przesyłać dane. W takiej sytuacji serwis aplikacyjny jest po prostu jakimś webserwisem. Serwis domenowy nie może nim być, bo domeny nie miesza się z infrastrukturą.

Wybitny Kaczor napisał(a):

Controller => Service Layer => Repository

Wystarczy, że tak to będzie wyglądać. Wszelka logika w serwisach, z kontrolera wywołuje się metody z serwisu, które następnie działają już na repozytoriach.

A co to ma wspólnego z DDD? ;]

Pewnie podejść DDD jest tyle ilu programistów, tak więc po prostu trzeba to zrozumieć. Dzięki za odpowiedzi.

Nie, DDD jest jedno, a że mało kto je implementuje prawidłowo, to inna rzecz.