Единая платформа данных: где CDO провести границу между центром и доменами
Финансовая служба хочет одну согласованную цифру продаж. Коммерческий блок — менять расчёты без очереди к центральной команде. Информационная безопасность — понимать, кто видит данные клиентов. Разработчики платформы — перестать разбирать каждое изменение статуса заказа вручную.Все четыре требования разумны. Но фраза «построим единую платформу данных» ещё не объясняет, кто будет принимать решения, оплачивать эксплуатацию и исправлять историю после ошибки.Разберём архитектурное решение на уровне CDO: какие функции имеет смысл централизовать, какие оставить предметным командам и как провести между ними проверяемую границу. Под доменом здесь понимается область бизнеса с собственными правилами и ответственным руководителем: например, продажи, платежи или логистика. Это не обязательно отдельный микросервис, департамент или кластер.Дальше — учебная ситуация, а не описание внедрения и его результатов. Предположим, у компании есть несколько каналов продаж, общий финансовый контур и команды, способные поддерживать собственные преобразования данных. Цель — согласованная управленческая отчётность и более независимое развитие аналитики. Субсекундный антифрод и управление складским оборудованием в границы этого решения не входят: у них другие требования к задержкам и отказам. Разобрать архитектуру