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

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

Легенда

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

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

1. Анемичная модель: Модель данных без логики.
2. ValueObject: Неизменяемое хранилище данных без уникального идентификатор
3. Entity: Объект c уникальным идентификатором
4. Aggregate: Объект содержащий в себе Entity. Обладает уникальным идентификатором.
5. Repository: Изолирует нас от того что мы используем. Хранилище наших Aggregate
6. UseCase/Interactor: Изолирует нас от того что использует нас. Например от ASP.NET, gRPC, WCF, WPF, WinForms. Может вызывать Repository когда это нужно. Сам почти ничего не делает и не хранит. Тут должна быть минимальная логика. Только использует Entity, Aggregate, ValueObject и Repository. В Анемичной модели наоборот делает все, тут вся логика.
7. DomainEvent: Событие которое случилось в Домене и на которое внешний мир должен как-то среагировать. Можно сделать просто булево свойство или коллекцию с объектами у вашего домена в которую добавлять события. Обрабатывать их можно в ApplicationService/UseCase/Interactor.

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

github.com/VictoremWinbringer/SnakeGameWithOnionAkaCleanArchitecture

Литература

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