Декомпозиция в стиле квантовой архитектуры

Какие способы декомпозиции на сервисы мы знаем? И самое главное: как именно сделать такую декомпозицию, в которой мы будем уверены?

Например, К. Ричардсон выделяет два основных подхода к декомпозиции:

По бизнес-возможностям (by business capability). Система разбивается на области, в которых бизнес генерирует прибыль. Бизнес-возможности организации определяют то, чем она является. Это более стабильное описание, в отличие от того, как организация ведёт свой бизнес. Например, обработка платежей будет всегда, и неважно, как именно она будет реализована.
По поддоменам (by subdomains). Способ декомпозиции системы на основе подходов Domain-driven design (DDD). Каждый поддомен определяет ограниченный контекст (bounded context), который соответствует одному сервису.

Есть и более экзотические методы, которые я описывал ранее в статье “Как еще определять границы микросервисов”.

И несмотря на то, что всё делаешь “по науке”, продолжает терзать мысль: всё ли правильно и как в этом убедиться.

Пожалуй, первое, что приходит на ум, это принципы ООП, сформулированные Р. Мартином, включая SRP (Single Responsibility) и CCP (Common Closure), а также его метрики успешности декомпозиции: абстрактность (соотношение абстрактных элементов к конкретным); нестабильность (соотношение исходящих связей компонента ко всем).

Однако всё это мне никогда не давало полной уверенности. Позже я понял причину: они нацелены в первую очередь на техническую сторону вопроса, а не прикладную; оценку существующего кода, а не того, который предстоит написать.

Думаю, по этой причине М. Ричардс и Н. Форд ввели понятие архитектурного кванта — уникального набора архитектурных свойств, действующих в рамках единицы развертывания — компонента (сервиса). При этом к свойствам предъявляются следующие требования.

Непредметный взгляд на проектирование. Функциональные требования определяют, что должно делать приложение, а архитектурные свойства задают эксплуатационные критерии успеха, способствующие реализации требований.
Влияние на структурные аспекты проектирования. Архитектурное свойство является таковым, если оно влияет на структуру проекта. Например, в одном случае безопасность — это архитектурное свойство, а в другом нет. При обработке платежей через сторонний сервис безопасность важна, но она не повлияет на структуру проекта и будет ограничена технологическими мерами (шифрование, хэширование и т.п.). А вот самостоятельная реализация платежей, возможно, потребует структурной и физической изоляции платёжного сервиса.
Ключевая или важная роль в успешности решения. Архитектурное свойство является таковым, если оно необходимо для успешной реализации. Поддержка каждого свойства усложняет проектирование, поддержка множества свойств — бессмысленна. Выбранные свойства должны работать на вас, а не наоборот.

О чём это говорит? Производительность, масштабируемость, безопасность, надёжность, доступность — это только слова! В рамках отдельно взятого компонента они могут стать архитектурными свойствами только в том случае, если без них успех проекта невозможен. Понимание этого позволяет сфокусироваться на самых важных вещах и правильно расставить приоритеты.

И как это помогает оценить успешность декомпозиции?

Возьмите два взаимосвязанных сервиса и определите для них 3 самых важных архитектурных свойства. Каждый сервис — архитектурный квант, он определяет границы действия архитектурных свойств. Мысленно следуя по связи между сервисами, проверьте её адекватность. Если производительный сервис зависит от непроизводительного; безопасный — от небезопасного; масштабируемый — от немасштабируемого и т.д., значит, вы сделали что-то не так.

Всем добра и правильной декомпозиции! Если тема показалась интересной, поддержите меня. В следующий раз разберём, что есть помимо cohesion и coupling, и зачем это на практике.

Понравилась статья?