Пост для любителей программной инженерии

Статья для телеграмм канала CDO Club: https://t.me/cdo_club

Первый раз встретил книгу, в которой автор так конкретно и настоятельно рассказывает про методы декомпозиции требований для разработки архитектуры компонентов/сервисов программной системы, сопровождая описание отличной аргументаций и практическими примерами Я таких хороших описаний ранее не встречал (если кто встречал, поделитесь). Да и вообще, тема декомпозиции требований абсолютно не раскрыта в области Computer Science, всех учат больше кодированию, тестированию и системному дизайну с точки зрения отказоустойчивость. В вот в области декомпозиции требований и solution architect основном доминирует метод “функциональной декомпозиции”, который вроде как вообще растет из ООП и примеров в книгах на тему ООП. Собственно его все и используют, хотя по мнению автора (и не могу не согласиться) он сугубо пагубен и не приводит к возникновению элегантных и хороших архитектур программных систем, наоборот, плодя неэффективности и потери времени и денег при разработке и развитии программных систем.

Тут надо сказать, что такое “хорошая архитектура”. Как и то, что “хороший код” это код, который легко менять под изменения требований, “хорошая архитектура” - поддерживает легкое и безболезненное внесение изменений в компоненты системы. То есть задача архитектора так определить структурные компоненты системы, что бы изменение каждого из них минимально влияли на все другие. Вообще то, что изменение требований считается болью ИТ разработчиков не правильно, большинство авторов наоборот пишут о том, что изменения требований - это жизнь, это происходит и это должно быть. А наша задача вести разработку так, что бы эти изменения поддерживать.

Так вот, функциональная декомпозиция разбивает систему на структурные элементы, определяемые функциональностью системы. Один из способов выполнения функциональной декомпозиции — создание сервисов для всех разновидностей функциональности. Этот способ декомпозиции приводит к взрывному росту количества сервисов, так как система сколько-нибудь приличного размера может содержать сотни видов функциональности. В этих сервисах часто будет дублироваться большой объем общей функциональности, адаптированной для конкретного случая. Поэтому внесение изменений в систему как правило начинает затрагивать большое количество сервисов и модулей и говорить тут о красивой и элегантной архитектуре не особо приходиться.

Автор предлагает использовать другой метод - “декомпозицию на основе нестабильности” (Volatility-based decomposition). Правда тут русский перевод неточен, я бы перевел название как “декомпозиция на основе изменчивости”. Идея тут в том, что бы выделить области в требованиях, вероятность изменений которых велико и инкапсулировать эти изменения в соответсвующие компоненты/сервисы системы. Изменения при этом могут исходить из 2-х “областей”:

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

Такой подход минимизирует количество изменений, которые надо будет вносить в компоненты системы, при изменении одного из них. Все изменения одной области “инкапсулируются” и макимально изолируются.

Мне такой подход показался очень правильным и элегантным. Это, конечно, краткое изложение идеи, подробнее читайте в первой главе книги "Совершенный софт" Лёве Джувел.