emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

Чтобы лучше вообразить то, что происходит в мозгу, когда объем единовременно рассматриваемой сложности превышает возможности краткосрочной памяти человека, посмотрите на эту картинку. Сколько точек вы видите? Ваши глаза не могут увидеть все 12 точек одновременно.…

Один из способов ввести мозг разработчика в состояние "умственного жонглирования" - это "звездная" ("божественная") модель, которая решает несколько проблем. Или, если сказать по другому, - совмещение нескольких моделей в границах одного компонента.

В таком случае, команда разработки, пытаясь внести изменения в код для решения конкретной проблемы, будет постоянно сталкиваться с нерелевантными деталями реализации другой модели, решающей другую проблему, что будет формировать паразитную когнитивную нагрузку.

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

При попытке компонентного разделения такой "исторически сложившейся" системы, например, при выделении компонента, ответственного за платежи, перед программистом возникает вопрос: а что делать, если для функционирования одного компонента нужна сущность, которая находится в другом компоненте? Возникает то, что получило название "распределенный монолит". Модель размазывается на несколько компонентов.

Это несущественно, пока система маленькая. Но по мере роста размеры системы это приводит к кризису и препятствует дальнейшему росту системы. Никто не знает какой атрибут сущности кем и где используется. Изменение одного атрибута по одной причине может привести к тому, что в системе отвалится что-то другое, совершенно не связанное с этой причиной, только лишь потому, что один и тот же атрибут одной и той же сущности используется для решения разных проблем. Становится невозможно за всем уследить.

С целью решения именно этой проблемы Alberto Brandolini предлагает проектировать сущности в самую последнюю очередь, когда уже известны границы моделей.

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

См. также:
- https://www.tgoop.com/emacsway_log/1152
- https://www.tgoop.com/emacsway_log/1295

👍6🔥3💯2

www.tgoop.com/emacsway_log/1385

2.6K viewsIvan, edited  Apr 23, 2024 at 15:21

Один из способов ввести мозг разработчика в состояние "умственного жонглирования" - это "звездная" ("божественная") модель, которая решает несколько проблем. Или, если сказать по другому, - совмещение нескольких моделей в границах одного компонента.

В таком случае, команда разработки, пытаясь внести изменения в код для решения конкретной проблемы, будет постоянно сталкиваться с нерелевантными деталями реализации другой модели, решающей другую проблему, что будет формировать паразитную когнитивную нагрузку.

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

При попытке компонентного разделения такой "исторически сложившейся" системы, например, при выделении компонента, ответственного за платежи, перед программистом возникает вопрос: а что делать, если для функционирования одного компонента нужна сущность, которая находится в другом компоненте? Возникает то, что получило название "распределенный монолит". Модель размазывается на несколько компонентов.

Это несущественно, пока система маленькая. Но по мере роста размеры системы это приводит к кризису и препятствует дальнейшему росту системы. Никто не знает какой атрибут сущности кем и где используется. Изменение одного атрибута по одной причине может привести к тому, что в системе отвалится что-то другое, совершенно не связанное с этой причиной, только лишь потому, что один и тот же атрибут одной и той же сущности используется для решения разных проблем. Становится невозможно за всем уследить.

С целью решения именно этой проблемы Alberto Brandolini предлагает проектировать сущности в самую последнюю очередь, когда уже известны границы моделей.

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

См. также:
- https://www.tgoop.com/emacsway_log/1152
- https://www.tgoop.com/emacsway_log/1295

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.