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


Происхождение

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

Важные моменты в архитектуре

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

Примеры использования

Варианты использования представляют собой намерение действия, которое выполняет программное обеспечение. Каждое поведение должно быть четким. Детали не должны влиять на бизнес-правила. Фреймворки, базы данных и apis не должны влиять на бизнес-правила.

Каждый вариант использования должен следовать принципу единой ответственности.
Например: Change и insert a product похожи, оба выполняют запрос к базе данных и делают персистенцию, но это разные сценарии использования. То есть, если намерение изменения отличается, то это должен быть другой useCase

Примеры использования рассказывают историю

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

  1. Примите и подтвердите имя
  2. Проверьте адрес и т.д..
  3. Узнайте кредитную историю.
  4. Если кредитная история менее 500, то отказать.
  5. Создайте клиента и активируйте оценку кредита

Архитектурные ограничения

Все, что не влияет непосредственно на бизнес-правила, должно находиться в другом архитектурном пределе.
Например: не фронтенд, не база данных будут изменять бизнес-правила приложения.

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

DTO (объект передачи данных)

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

Он отвечает за получение этих данных и их транспортировку через архитектурные границы. Кроме того, DTO — это анемичный объект, у него нет правил, у него есть только данные.

Как правило, для каждого системного намерения нужны разные DTO, например, для создания продукта и обновления продукта нужны разные поля, по крайней мере, для обновления нужно еще одно поле (ID).

Ведущие

Объекты трансформации, их функция заключается в адаптации входного DTO к правильному формату для получения результата, например: JSON, Protobuf, GraphQl, CLI и т.д.

  input = new CategoryInputDto("name")
  output = CreateCategoryUseCase(input);
  jsonResult = CategoryPresenter(output).toJson();
Войдите в полноэкранный режим Выход из полноэкранного режима

В этом примере мы передаем входной DTO и получаем выходной dto, а затем используем презентер для преобразования этого выходного dto в объект json и возврата его пользователю

Организации

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

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

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

Оцените статью
Procodings.ru
Добавить комментарий