Чистая архитектура: варианты использования
Что такое вариант использования?
В чистой архитектуре прецедент — это часть бизнес-логики, представляющая одну задачу, которую должна выполнить система. Вариант использования инкапсулирует правила и логику, необходимые для выполнения задачи, и определяет входы и выходы, необходимые для операции.
Вариант использования обычно реализуется как автономный модуль (класс или функция), который отвечает за координацию потока данных между различными уровнями системы, такими как уровень предметной области и уровень представления. Вариант использования часто запускается действием пользователя (нажатием кнопки) или событием (вызовом API) в системе и может привести к изменению состояния системы или данных, которые сохраняются или извлекаются.
Вот пример варианта использования:
// File: AddToCartUseCase.swift
protocol AddToCartUseCase {
func execute(product: Product, quantity: Int)
}
class AddToCartUseCaseImpl: AddToCartUseCase {
private let cartRepository: CartRepository
init(cartRepository: CartRepository) {
self.cartRepository = cartRepository
}
func execute(product: Product, quantity: Int) {
var cart = cartRepository.getCart()
let cartItem = CartItem(product: product, quantity: quantity)
cart.items.append(cartItem)
cartRepository.saveCart(cart: cart)
}
}
Пример написан на Swift, но вы можете использовать ту же базовую концепцию и на других языках программирования
Используя варианты использования для инкапсуляции бизнес-логики системы, мы можем сделать код более модульным, тестируемым и удобным для сопровождения, поскольку варианты использования можно легко протестировать и изменить, не затрагивая другие части системы. Варианты использования также помогают отделить бизнес-логику от деталей реализации, таких как пользовательский интерфейс или хранилище данных, что может сделать код более адаптируемым и гибким.
Вариант использования — это связный модуль или компонент, имеющий четкую и четко определенную цель или ответственность, и все его элементы тесно связаны с этой целью. Другими словами, элементы варианта использования должны работать вместе для достижения единой цели или задачи, не полагаясь на элементы вне модуля или компонента.
Это помогает уменьшить сложность системы, разбивая ее на более мелкие и более управляемые части.
Где должен быть размещен вариант использования?
Варианты использования обычно находятся на уровне предметной области, который содержит бизнес-правила и логику, не зависящие от какой-либо конкретной технологии или инфраструктуры.
Уровень предметной области отвечает за представление бизнес-концепций и сущностей системы, а также за определение вариантов использования и операций, которые можно выполнять с этими сущностями. Варианты использования на уровне предметной области инкапсулируют определенные бизнес-правила и логику, необходимые для выполнения операции, и определяют входы и выходы, необходимые для операции.
Уровень предметной области часто реализуется как набор классов, интерфейсов или функций, которые представляют бизнес-концепции и варианты использования, и обычно изолирован от уровня представления и уровня данных. Варианты использования на уровне предметной области не должны иметь каких-либо прямых сведений о пользовательском интерфейсе или конкретном механизме хранения данных, а вместо этого должны взаимодействовать с этими уровнями через четко определенные интерфейсные контракты.
Сохраняя варианты использования на доменном уровне, мы можем сделать систему более модульной, гибкой и адаптируемой к изменениям. Это также может сделать код более пригодным для тестирования, поскольку уровень предметной области можно тестировать независимо от других уровней, используя фиктивные реализации зависимостей.
Почему мы должны разбивать варианты использования на отдельные файлы? Разве мы не можем вместо этого просто поместить их все в один модуль?
Предпочтительно иметь варианты использования в виде отдельных файлов:
- Разделение ответственности: система становится более гибкой и модульной, что позволяет легче адаптироваться к изменяющимся потребностям бизнеса.
- Удобочитаемость: код становится более читаемым и понятным, поскольку каждый вариант использования имеет четкую и четко определенную цель.
- Тестирование: легче тестировать, так как каждый вариант использования можно тестировать независимо от других.
- Повторное использование: их легче повторно использовать в других частях системы или даже в других проектах. Это повышает общую эффективность и ремонтопригодность.
- Гибкость: каждый вариант использования можно изменить или расширить, не затрагивая другие части системы.
Откуда мы будем вызывать вариант использования?
Варианты использования обычно вызываются из уровня представления. Уровень представления отвечает за обработку пользовательского ввода и представление данных пользователю (таких как веб-страница, мобильное приложение или настольное приложение), а также за любые компоненты ввода/вывода (такие как API, системы обмена сообщениями или файловые системы), которые используются для взаимодействия с пользователем или другими системами.
Когда пользователь взаимодействует со слоем представления, входные данные обычно передаются соответствующему варианту использования. Затем вариант использования выполняет необходимую бизнес-логику и возвращает результаты.
Заключение
Использование вариантов использования в разработке программного обеспечения дает ряд преимуществ. Инкапсулируя определенные части бизнес-логики в отдельные варианты использования, система становится более модульной, гибкой и адаптируемой к изменяющимся потребностям бизнеса.
Сценарии использования можно легко тестировать и повторно использовать в других частях системы, не беспокоясь о конкретных деталях пользовательского интерфейса или хранилища данных.
Варианты использования помогают отделить бизнес-логику от остального кода, упрощая управление, тестирование и изменение. Сценарии использования также позволяют абстрагировать логику доступа к данным от бизнес-логики, что может сделать код более гибким и простым в обслуживании с течением времени.
