Чистая архитектура на практике

Чистая архитектура в описании Дяди Боба не дает ответ на вопрос где разместить cross-cutting concerns (также известные как сквозная функциональность), extension-методы и хелперы. Однако такая инфраструктура есть в каждом проекте. Покажем, где ее разместить.

Что такое бизнес-логика и entities. Что поместить в компонент Entities кроме сущностей предметной области. Какую модель лучше использовать: rich или anemic. Где разместить бизнес-логику в случае анемичной модели.

В каком компоненте разместить интерфейсы и реализацию инфраструктуры для доступа к данным. Стоит ли объединять в одном компоненте entities и интерфейсы репозиториев. Как организовать ссылки между Entities, UseCases, интерфейсами и реализацией доступа к данным. Стоит ли писать собственную реализацию Repository и UnitOfWork для абстракции ORM.

Как изменится состав компонентов и взаимосвязей между ними, если в проекте много инфраструктуры и интеграций со сторонними системами. Что лучше: два больших компонента с интерфейсами и реализациями всей инфраструктуры или отдельный компоненты под интерфейс и реализацию каждой инфраструктуры или интеграции. Плохо ли это, иметь в проекте много мелких, но слабо связанных компонентов с четкой областью ответственности.

Что такое логика приложения (Application Logic). Что такое интерактор. Как его лучше реализовать: в виде сервиса (ApplicationService), каждый метод которого представляет собой юскейс, или в CQRS-стиле, когда для каждого юскейса создается отдельный класс-обработчик. Плохо ли иметь в системе много маленьких и незавичимых классов с четкой областью ответственности.
Пошаговое руководство по миграции от сервисов к хендлерам.

Где разместить общую логику для разных юскейсов. Можно ли для переиспользования логики между юскейсами пользоваться наследованием юскейсов и geneic-параметрами. Можно ли использовать ApplicationServices, если логика приложения реализована в  CQRS-стиле с отдельным классом-обработчиком каждого юскейса и какова новая роль ApplicationServices.

Контроллеры MVC-фреймфорка и контроллеры в чистой архитектуре - это одно и то же или нет. Можно ли вызывать разные юскейсы из одного метода контроллера. Когда стоит, а когда не стоит выносить контроллеры в отдельный компонент.
Когда не работает правило зависимостей.

Что Дядя Боб имеет ввиду под фреймворками: только стороние процессы или и код для взаимодействия с ними. Когда стоит, а когда не стоит писать обертки для используемых фреймворков и библиотек. Нужно ли писать обертку для ORM.

Что такое кричащая архитектура. Как сделать инфраструктуру тоже кричащей. Правила удобного и однозначного именования компонентов. Названия компонентов, которых стоит избегать.

Удобный трюк, как при помощи делегатов избежать закисимости бизнес-логики от инфраструктуры, даже если бизнес-логика явно использует инфраструктуру.

Background Jobs - неотъемлемая часть огромного количества проектов. Часто по ночам запускаются операции расчетов и обновления статусов каких-то объектов или синфронизации с внешними системами. Посмотрим, как решается эта задача в рамках чистой архитектуры.

По ходу погружения в чистую архитектуру мы отрефакторили демо-проект со слоистой на чистую архитектуру. Давайте акцентируем внимание на том, как мы это сделали и сформулируем правила, которые позволят сделать аналогичный рефакторинг с любым проектом.

Часто говорят, что до анализа требований невозможно сказать, какой будет архитектура будущего проекта. Посмотрим, насколько такое утвержденеи соответствует действительности.

Подводим итоги чему научились в этом разделе.

От чего зависит состав компонентов проекта и взаимозвязи между ними. Варианты масштаба проектов: микросервис, стартап, средний и большой проект, что понимается под каждым вариантом.

Из каких компонентов и связей между ними будет состоять типичный микросервис, реализованный в соответствии с чистой архитектурой

Обзор проекта, реализующего типичный микросервис

Чем типичный стартап, сделанный по чистой архитектуре, будет отличаться от типичного микросервиса. Как изменится состав компонентов и их связи.

Пошаговое руководство по масштабированию проекта от микросервиса до стартапа

Как изменится состав компонентов и взаимосвязи между ними для типичного стартапа, который "выстрелил" и его жизненный цикл продолжается после запуска.

Как изменится состав компонентов и из взаимосвязи для стартапа, в который добавляется много бизнес-логики

Как изменится состав компонентов и их взаимосвязи для стартапа, в который добавляется много логики приложения (application logic)

Как изменится состав компонентов и из взаимосвязи для среднего проекта, когда в нем появляется несколько входных точек (Backend For Frontend, BFF) или независимая бизнес-логика (разные Bounded Context в терминах DDD).

Чему научились в этом разделе

Где найти проект на гитхабе, кто его автор

Обзор демо-проекта, из каких компонентов он состоит, что находится в каждом компоненте и каковы сзвимосвязи между компонентами

Где проект соответствует, а где не соовтетствует чистой архитектуре. Удобное ли именование компонентов проекта.

Выделяем компоненты, такие как Entities, выносим в них существующий код и настраиваем взаимосвязи так, чтобы проект соовтетствовал чистой архитектуре. Делаем более понтяным именование компонентов.

Рефакторим инфраструктуру: разделяем Infrastructure.Implementation и DataAccess

Переписываем логику приложения с ApplicationServices на CQRS Handlers

Вынос контроллеров в отдельный компонент

Вывод о том, можно считать данный демо-проект образцом для подражания в продакшен-проектах

Как найти демо-проект на гитхабе и кто его автор

Обзор компонента Domain и анализ на соответствие требований чистой архитектуры. Добавление доменных сервисов

Выделение компонента Infrastructure.Interfaces из компонента Application

Выделение компоненов для логики приложения из компонента Application

Выделение отдельных компонентов для интерфейса и реализации каждой инфраструктуры (доступ к данным, отправка сообщений)

Выделение контроллеров в отдельный компонент

Сравнение этого демо-проекта с демо-проектом из предыдущего раздела и из материалов курса.
Вывод о том, можно считать данный демо-проект образцом для подражания в продакшен-проектах.

Обзор того, чему научились в курсе. Рекомендации по дальнейшему погружению в тему чистой архитектуры и ее применения на практике.