H Onion aka Clean Architecture в черновиках Tutorial

В прошлой своей статье я вскользь упомянул Onion архитектуру. Там было в основном про то что не надо лишние библиотеки и папки создавать, что надо делить код на модули и что можно писать код прямо в контроллер и использовать Entity Framework там же напрямую НО Домен все равно должен быть отдельно и все вычисления должны быть в нем. Теперь хочу поговорить о луковой архитектуре. Больше всего подходящей для сложного приложения с большим количеством логики. В этой статье в качестве примера я буду использовать игру "Змейка" потому что в ней достаточно логики для «богатого» домена

Легенда

1. Красным цветом указана зависимости.
2. Зеленым цветом указаны важные группы. Под — слои
3. Синим цветом разделены основные слоим которые желательно держать отдельно

Терминология

1. ValueObject: Неизменяемое хранилище данных без уникального идентификатор
2. Entity: Объект c уникальным идентификатором
3. Aggregate: Объект содержащий в себе Entity. Обладает уникальным идентификатором. Entity одного типа не может быть в двух агрегатах одновременно
4. DomainServices: Изолирует нас от того что мы используем. Например от ADO.NET, NLogger, Redis, RabbitMQ, AppMetrics, ElasticSearch
5. ApplicationServices: Изолирует нас от того что использует нас. Например от ASP.NET, gRPC, WCF, WPF, WinForms. Может вызывать DomainServices когда это нужно. Сам почти ничего не делает и не хранит. Только использует Entity, Aggregate, ValueObject и DomainService

Пример: Игра змейка

github.com/VictoremWinbringer/SnakeGameWithOnionAkaCleanArchitecture

Литература

1. Domain Driven Design – simplifying the complicated
2. Заблуждения Clean Architecture