Организация структуры кодовой базы

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Инженеру

Структура кодовой базы в «чистой архитектуре»

Отличный пример структуры папок — это проявление слоистой архитектуры с элементами hexagonal (ports & adapters) и domain-driven Проектирование.

Ниже — назначение типичных директорий:

Директория	Назначение	Комментарий
entity, value-objects	Ядро предметной области. Идентичность и инварианты бизнес-логики.	Должны быть свободны от зависимостей (чистые классы).
use-Кейсы	Оркестрация операций над сущностями. Реализуют бизнес-транзакции.	Зависят от entity, но не от инфраструктуры.
interface / ports	Абстракции (интерфейсы) для внешних зависимостей (БД, API, FS).	Определяют что, но не как.
infrastructure	Реализации интерфейсов из interface.	Содержат SqlConnection, HttpClient, File.WriteAllText и т.п.
services	Общая логика, не привязанная напрямую к use-case (например, хэширование, валидация).	Может быть переиспользована.
dtos	Данные Transfer Objects — для сериализации и межслойного обмена.	Должны быть простыми контейнерами данных.
handlers, events, event-dispatcher	Реализация событийной модели (in-process).	Часто — mediator или observer pattern.
decorators	Cross-cutting concerns (логгирование, кэширование, валидация) через декораторы.	Соответствует принципу Open/Closed.
filters, interceptors	Обработка запросов/ответов на уровне фреймворка (например, в ASP.NET Core).	Не должны содержать бизнес-логику.
errors	Семантические типы ошибок (не Exception напрямую).	Позволяют явно обрабатывать failure modes.
shared, utils, constants, types	Вспомогательные элементы.	Следует минимизировать — избыток utils признак низкой связанности модели.

Такая структура упрощает модульное тестирование, заменяемость компонентов и поддержку. Однако она оправдана при достаточной сложности предметной области; для простых CRUD-приложений — избыточна.

---