Архитектура ПО

Практическая ситуация: доменный модуль напрямую зависит от инфраструктурного. Как изменить границу между ними, чтобы сохранить независимость домена?

После изменения внутреннего алгоритма модуля приходится менять его потребителей. Какой дефект границы это показывает?

Команда выделила сервис из монолита, но его операции требуют общей транзакции с соседним сервисом. Какой архитектурный сигнал показывает, что границу выделили неверно?

Разберите механизм, из-за которого цикл зависимостей препятствует независимой эволюции модулей. В системе заказов границы заданы так:

module Заказы
    import Оплата
    function создатьЗаказ() { Оплата.проверитьЛимит() }

module Оплата
    import Заказы
    function отменитьОплату() { Заказы.найтиЗаказ() }

При переходе от синхронного вызова к обмену событиями какую ключевую связанность получает система вместо прямой зависимости вызова?

В системе два модуля используют одну таблицу и независимо меняют её схему. Какой механизм связывает их эволюцию?

В чём ключевое архитектурное отличие вертикального среза от горизонтальных слоёв при изменении одной бизнес-возможности?

Старые потребители ещё не обновлены после изменения публичного контракта модуля. Как организовать эволюцию, чтобы не требовать одновременного релиза?

Сравнение: чем отличается цена границы взаимодействия в модульном монолите и микросервисной системе?

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

Работающий монолит нужно заменить без остановки бизнеса. Какой механизм миграции позволит безопасно переводить функциональность частями?

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

В модуле каталога потребитель получает изменяемое внутреннее состояние. Какой дефект архитектурной границы показан в коде?

модуль Каталог {
    приватное товары

    функция получитьТовары() {
        вернуть товары
    }
}

список = Каталог.получитьТовары()
список.удалить(0)
список[0].внутренняяСебестоимость = 0

Как цепочка последовательных синхронных вызовов между сервисами влияет на надёжность пользовательского сценария?

Каким образом отдельные модели в разных ограниченных контекстах уменьшают семантическую связанность системы?

По какому признаку единая причина изменения помогает определить границу модуля?

Несовместимое изменение схемы данных требует одновременного обновления всех потребителей. Какой поэтапный приём позволит избежать этого?

От чего зависит независимое масштабирование части программной системы?

Событийный обработчик может получить одно и то же событие повторно из-за повтора доставки. Какое свойство операции не позволяет повторно изменить бизнес-состояние?

На ревью предлагают вынести общий код в библиотеку, чтобы два модуля не дублировали его. Как понять, что библиотека станет скрытой общей границей?