Warstwy w projekcie opartym na domenie

Question

W projekcie opartym na domenie dziedzina domenowa nie ma zależności od innych warstw. to jest interfejs repozytorium z warstwą domeny, podczas gdy implementacja jest w warstwie infrastruktury.

Jednak kontekst ograniczony (z domeną + infra) jest wdrażany jako jedna jednostka/wdrażalny. A warstwy są faktycznie LOGICZNE, a nie FIZYCZNE. Więc jaka jest prawdziwa zaleta rysowania tego wirtualnego separatora warstw między domeną a infrastrukturą?

Aktualizacja

W tradycyjnej domeny podejście warstwowe (serwis) mówi się, że zależy od infra warstwy. Jednak jeśli chodzi o domenę DDD/clean/hexagonal architektury, jest ona niezależna od innych warstw. Jednak zdarzenie z podejściem czystym/sześciokątnym nadal warstwa domeny ma interfejs, który jest zaimplementowany przez warstwę infra.

Dlatego niezależnie od tego, czy stosujesz metodę DDD/heksagonalną, czy tradycyjną metodę warstwową, nadal musisz pozorować repozytoria itd., Np. Domena nie jest w rzeczywistości niezależna. Jaka jest Twoja opinia?

Answer 1

Założeniem Domain Model pattern to, że domena modelu jest albo najbardziej skomplikowana część aplikacji, lub część, która zmienia się częściej niż w innych częściach.

Wzór modelu domeny próbuje rozwiązać ten problem przez uniezależnienie modelu domeny od innych problemów. Jedną z zalet tego jest to, że możesz testować model domeny w izolacji jego zależności. Można również zmieniać model domeny bez konieczności zmiany innych części aplikacji.

To są główne zalety, ale istnieją również wady wady:. Oddzielenie może sprawić, że podstawa kodu będzie trudniejsza w nawigacji, a także będzie wymagać dużej liczby map między warstwami. To, czy this is worthwhile jest uzależnione od konkretnych okoliczności (jak skomplikowany jest Model Domeny, jakie masz inne alternatywy weryfikacji), czy nie.

Answer 2

Najważniejszym czynnikiem jest umożliwienie zmiany różnych warstw bez wpływu na siebie nawzajem. Na przykład często testuję swoją warstwę domeny niezależnie od warstwy infrastruktury. Robię to, kpiąc z moich DAO i repozytoriów, co pozwala moim testom działać znacznie szybciej i sprawia, że ​​są znacznie mniej kruche.

Używam go również, gdy moje repozytorium kończy się wymaganiem nowej implementacji (Oracle vs MS SQL vs Web Service). Znacznie zmniejsza to Twoją złożoność, gdy nie musisz przepisywać całej aplikacji, gdy usługa zaplecza zmieni się z ciebie.

Na koniec dzielenie tego pomaga w uzyskaniu SRP. Integracja twojej warstwy bazy danych z twoją domeną zwykle pozwala ci to pominąć (przynajmniej w moim doświadczeniu). Nie zmusza cię do tego, ale z pewnością zachęca do złych zachowań.

To jest ten sam powód, dla którego nie pisujemy naszej logiki domeny w naszym interfejsie użytkownika. Dla każdego wystarczająco małego przykładu, to strata czasu. Jego wartość staje się widoczna tylko wtedy, gdy masz dużą, złożoną aplikację.