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