Границы и владение — Примеры

Пример 1 — Разделение, которое расширило каждое изменение

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

сервис базы данных  владеет таблицами orders и pricing       команда: платформа
сервис правил       правила ценообразования и правила доставки  команда: платформа
веб-сервис          эндпоинты, которые вызывают оба выше        команда: оформление
каждое изменение функции затрагивало все три сервиса

Решение

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

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

Пример 2 — Два сервиса читают один набор таблиц

Заметка ниже описывает, как отчётность получает свои числа, поэтому измените её так, чтобы каждый сервис владел своими данными и был доступен только через интерфейс, и назовите изменение столбца, которое после этого перестаёт ломать другой сервис.

сервис заказов      пишет orders(id, status, total) и order_lines
сервис отчётности   читает обе таблицы напрямую, те же учётные данные, та же база

Решение

сервис заказов      владеет orders и order_lines; выставляет /orders/{id} и ежедневный экспорт
сервис отчётности   хранит копию нужных полей, обновляемую из экспорта
изменение столбца, которое больше не ломает отчётность: переименование total в таблице orders

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