What else changes for different reasons? The use cases themselves! The use case for adding an order to an order entry system almost certainly will change at a different rate, and for different reasons, than the use case that deletes an order from the system. Use cases are a very natural way to divide the system.
At the same time, use cases are narrow vertical slices that cut through the horizontal layers of the system. Each use case uses some UI, some application-specific business rules, some application-independent business rules, and some database functionality. Thus, as we are dividing the system into horizontal layers, we are also dividing the system into thin vertical use cases that cut through those layers.
To achieve this decoupling, we separate the UI of the add-order use case from the UI of the delete-order use case. We do the same with the business rules, and with the database. We keep the use cases separate down the vertical height of the system.
—
Что еще меняется по разным причинам? Сами варианты использования! Вариант использования для добавления заказа в систему ввода заказов почти наверняка будет меняться с другой скоростью и по другим причинам, чем вариант использования, который удаляет заказ из системы. Варианты использования - это естественный способ разделения системы.
В то же время варианты использования представляют собой узкие вертикальные срезы, проходящие через горизонтальные уровни системы. Каждый вариант использования включает некоторый пользовательский интерфейс, какие-то бизнес-правила, специфичные для приложения, некоторые бизнес-правила, не зависящие от приложения, и а также определённую работу базой данных. Таким образом, разделяя систему на горизонтальные слои, мы также разделяем ее на тонкие вертикальные варианты использования, которые проходят через эти слои.
Чтобы добиться такого разделения, мы отделяем пользовательский интерфейс варианта использования с добавлением заказа от пользовательского интерфейса варианта использования с удалением заказа. Мы делаем то же самое с бизнес-правилами и базой данных. Мы разделяем варианты использования по вертикали системы.
— Роберт Мартин, Clean Architecture, глава 16. Independence, раздел Decoupling Use Cases
Значит ли это, что Чистая архитектура ближе к вертикальной, чем к слоёной? И в коде по чистой архитектуре должна быть пачка интерфейсов в духе RegisterUserGateway, DeleteUserGateway и т.п. вместо UsersGateway.
Как знать - анкл Боб почему-то решил не показывать реальный пример реализации чистой архитектуры.
Может в этом секрет популярности - написать в целом убедительный, но внутренне противоречивый текст, в котором каждый найдёт то, что ему нравится?
Не спрашивайте как меня опять занесло перечитывать эту книгу.
#clean_arch@ergonomic_code #books@ergonomic_code