"Про отличия в доменных моделях Хороший комментарий поступил: Как-бы похожие задачи в банках часто сильно отличаются в кажущимися неважными мелочами, которые в реальности приводят к очень разным функциям. Ну, например, в одном банке считают, что эквайринговый клиент и эмиссионные клиент - всегда различные (например, юрлицо с терминалами и то же юрлицо с картами - разные, так как ими занимаются разные департаменты), а в другом - могут быть одинаковые. А отсюда идет принципиальная разница в датамодели, да и в событийной модели и в возможных функциональностях и много в чем. По сути - ""различия в онтологии привели к различиям в поведении"". И вот понимание таких тонкостей - часто гораздо важнее NFR. И хорошо, что есть вполне четкий ответ. Ключевой принцип – информация моделируется как она есть, а не как она выглядит для банка. В описанном комментарии информация моделируется через призму организационной структуры (департаменты). Здесь эквайринговый клиент и эмиссионный клиент – это разные сущности, даже если это одно юридическое лицо. Критерий разделения здесь – кто обслуживает внутри. Если строить формальную онтологию, то клиентская сущность будет определяться через реальное юридическое лицо с множеством ролей и это буквально референсное решение: Есть сущность Party (сторона), представляющая реальное действующее лицов в бизнес-системе. Сторона может быть физическим лицом, юридическим лицом или группой (группа физлиц/организаций). Важно то, что Сторона содержит данные, являющиеся инвариантными отсносительно ролей, то есть не меняются в зависимости от того, в какой роли выступает Сторона. Role (роль стороны отношений) – это функция или контекст, в котором Сторона принимает участие в конкретной бизнес-деятельности. Роль содержит данные, специфичные для данной функции. Здесь важно то, что роль – это отдельная сущность со своими атрибутами, которые имеют смысл только в контексте этой роли. Пример: Физ Лицо (Сторона) - Сотрудник(Роль) Физ Лицо (Сторона) - Спикер (Роль), Участник конференци (Роль) Организация(Сторона) - Эквайринговый клиент (Роль), Эмиссионный клиент (Роль) Это дает ряд премуществ: • Четкое разделение между «кто» и «в какой роли» • Простота добавления новой роли без изменения структуры Стороны • Явная связь через Party_ID Дополнив онтологию признаком Relationship (Отношение) между Сторонами можно дальше усилить модель: Сторона1 владеет Сторона2 Сторона3 является директором Сторона4 Подробнее: https://bian.org/servicelandscape-9-0/views/view_38585.html То есть, цитируя себя же: Так почему системы так сильно отличаются? Наконец, можно к месту применить фразу «так исторически сложилось». Но это не значит, что так должно быть или должно быть всегда."