Реализация чистой архитектуры в WEB приложении
Всем привет, я читаю книгу Р. Мартина "Чистая архитектура". В ней приводится такая структура приложения:
Я разрабатываю телеграмм бота для автоматизации рассылок инстаграм. У меня получилась следующая структура: Сущности: User, Instagram, Work(сущность фоновой задачи), интерфейсы вариантов использования, доступа к данным и тд. Сущности не требуют в себе никакой критической бизнес логики, просто структуры данных. От сущностей зависит проект с бизнес логикой (варианты использования, далее: слой с бизнес логикой). Там определены сервисы ответа на команды ботом, запуск задач, оплата и тд. От бизнес логики зависят несколько компонентов, они все реализуют интерфейсы, определенные в сущностях. Это доступ к данным, отправка запросов телеграмму, инстаграму, работа с платежной системой, компонент MVC.
Вопрос заключается в чем.
- Правильно ли хранить все интерфейсы в сущностях, или интерфейсы для доступа к данным к примеру должны находиться в проекте с бизнес логикой?
- Детали (тот же проект доступа к данным) должны общаться с слоем с бизнес логикой с помощью DTO. Где их хранить? В Сущностях или в слое с бизнес логикой?
- Может ли бизнес логика контактировать с деталями (компоненты, зависящие от нее) с помощью сущностей? К примеру репозиторий будет возвращать объекты сущностей из бд? Или для них нужно создавать отдельные DTO (InstagramDTO, UserDTO...) и при необходимости мапить их в сущности в слое с бизнес логикой.
- И вообще, может ли слой с бизнес логикой зависеть от сторонних библиотек? Автомапера там, CSVHelper и тд, или все сторонние библиотеки необходимо оставить для компонентов, зависящих от бизнес логики?
- Если все интерфейсы находятся в сущностях, то может быть детали должны зависеть от сущностей, а не от слоя с бизнес логикой? В таком случае изменения в бизнес логике не потребуют согласования с компонентами (если не изменяется какая-то очень важная часть бизнес логики)?
Ответы (1 шт):
Дисклаймер Если у вас полтора класса в проекте, то вам вероятно и не надо заморачиваться с архитектурой. Я бы вообще почитал сначала Мартина Фаулера - Шаблоны корпоративных приложений, а потом уже читал дядю Боба. Также полезно знать, что универсальной архитектуры для всего нет в природе. Вы можете однажды обнаружить, что натягиваете сову на глобус.
Теперь по порядку.
Интерфейсы для доступа к данным должны находиться там, где это имеет смысл. Обычно где то рядом с классами, которые используют эти интерфйсы или где то в отдельной библиотеке "ядра" вашего приложения. Но я бы ещё спросил себя - а мне надо эти интерфейсы? У вас много реализаций доступа к данным? Не плодите ли вы интерйесы впустую?
Бизнес логика не общается с помощью DTO. DTO - это просто объект передачи данных. Зачем этим классам лежать рядом с логикой? Если они часть интерейсов - пусть лежат с интерфейсами рядом. Если они часть доступа к данным - пусть там и находятся. Сущности ваши вообще ничего не должны знать о том, что они вообще хранятся или передаются куда либо. Потому DTO рядом с сущностями не хранят.
Может быть что угодно. Лично я предпочитаю не мешать хранение и доменные модели просто потому, что модель хранения может отличаться от модели-сущности. Но это не правило. Действуйте так, как имеет смысл для вашего приложения.
Это вообще непонятный вопрос. Для взаимодействия с внешним миром у вас есть всякие контроллеры/шлюзы, там и добавляйте свои зависимости. Как вы делаете уровень доступа к БД, также и уровень доступа к CSV или HTTP или что там у вас есть.
Непонятно, зачем интерфейсам находиться в сущностях? И как вы разделяете бизнес логику и сущности тогда? И что за детали? Почитайте про принцип инверсии зависимости.
p.s. Фоновая задача называется Job, а не Work.