Прямоугольники и стрелочки

Причины декомпозиции

«Вах, зачем ты предлагаешь мне декомпозицию? Как это снизит связанность? Связи останутся те же, только часть из них станет внешними. В итоге мы получим медленные, ненадежные взаимодействия» (из разговора с заказчиком).

1. Говоря о причинах декомпозиции, многие вспоминают связанность.
Связанность (англ. coupling, рунглиш. каплинг) — мера взаимосвязи элементов системы.
Мол, декомпозировать нужно для того, чтобы уменьшить связанность.
Отнюдь.
Так можно договориться до того, что повышать качество системы нужно ради хорошего коэффициента покрытия модульными тестами.

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

3. Возьмём, к примеру, первичную декомпозицию системы. В редких случаях все ее части строятся на одной онтологии. Зачастую система распадается на множество элементов (доменов, предметных областей), описываемых различными языками. Заставьте разработчиков думать сразу на нескольких языках (Ubiquitous Language) и повторите судьбу строителей вавилонской башни.
Одним из паттернов первичной декомпозиции у Криса Ричардсона является декомпозиция по предметке
(см. https://microservices.io/patterns/decomposition/decompose-by-subdomain.html).
И где здесь про связанность?

4. Если уж говорить про метрики, то лучшей метрикой декомпозиции является сцепленность.
Сцепленность (англ. cohesion) — мера «близости» элементов системы.
Упрощая, мы можем проранжировать все связи по «правильности» и провести декомпозицию так, чтобы «правильные» связи попадали в общий элемент, а «неправильные» связывали элементы между собой.
Минимизировать количество и степень неправильных связей (снизить связанность) — это задача распределения ответственностей и дизайна взаимодействий, а не декомпозиции.

5. Список «правильных» и «неправильных» связей можно найти в стандарте ISO/IEC/IEEE 24765.
Однако этот список изначально был ориентирован на низкоуровневый дизайн и поэтому не полон.
Например, в этом списке есть сцепленность по общим данным, но нет сцепленности по общему языку, которую мы активно используем.

6. Хотелось бы хотя бы тезисно накидать алгоритм декомпозиции, указав, какие сцепки используются на разных уровнях иерархии системы.

www.tgoop.com/rect_arrow/288

774 viewsMaxim Yunusov, edited  Oct 5, 2024 at 12:09

Причины декомпозиции

«Вах, зачем ты предлагаешь мне декомпозицию? Как это снизит связанность? Связи останутся те же, только часть из них станет внешними. В итоге мы получим медленные, ненадежные взаимодействия» (из разговора с заказчиком).

1. Говоря о причинах декомпозиции, многие вспоминают связанность.
Связанность (англ. coupling, рунглиш. каплинг) — мера взаимосвязи элементов системы.
Мол, декомпозировать нужно для того, чтобы уменьшить связанность.
Отнюдь.
Так можно договориться до того, что повышать качество системы нужно ради хорошего коэффициента покрытия модульными тестами.

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

3. Возьмём, к примеру, первичную декомпозицию системы. В редких случаях все ее части строятся на одной онтологии. Зачастую система распадается на множество элементов (доменов, предметных областей), описываемых различными языками. Заставьте разработчиков думать сразу на нескольких языках (Ubiquitous Language) и повторите судьбу строителей вавилонской башни.
Одним из паттернов первичной декомпозиции у Криса Ричардсона является декомпозиция по предметке
(см. https://microservices.io/patterns/decomposition/decompose-by-subdomain.html).
И где здесь про связанность?

4. Если уж говорить про метрики, то лучшей метрикой декомпозиции является сцепленность.
Сцепленность (англ. cohesion) — мера «близости» элементов системы.
Упрощая, мы можем проранжировать все связи по «правильности» и провести декомпозицию так, чтобы «правильные» связи попадали в общий элемент, а «неправильные» связывали элементы между собой.
Минимизировать количество и степень неправильных связей (снизить связанность) — это задача распределения ответственностей и дизайна взаимодействий, а не декомпозиции.

5. Список «правильных» и «неправильных» связей можно найти в стандарте ISO/IEC/IEEE 24765.
Однако этот список изначально был ориентирован на низкоуровневый дизайн и поэтому не полон.
Например, в этом списке есть сцепленность по общим данным, но нет сцепленности по общему языку, которую мы активно используем.

6. Хотелось бы хотя бы тезисно накидать алгоритм декомпозиции, указав, какие сцепки используются на разных уровнях иерархии системы.

BY Прямоугольники и стрелочки