Изоляция данных — следует ли внешней системе-поставщику данных знать о внутренних идентификаторах системы-потребителя данных?
Есть две системы - система управления НСИ (Система1) и некая производственная система (Система2).
Номенклатура создается в Системе1, затем переливается в Систему2.
Иерархия номенклатур в системах разная - разная структура папок, иначе говоря.
Когда Система1 отправляет данные о номенклатуре в Систему2, то сначала в некоем своем внутреннем хранилище она ищет, какая папка Системы1 соответствует папке Системы2. В данных, отправленных в Систему2, содержится идентификатор именно папки Системы2. То есть Система1 должна знать все о структуре папок Системы2 и внутри себя хранить все соответствия.
Далее, Система1 хранит в себе идентификатор номенклатуры из Системы2. В Системе1 есть свой идентификатор и он, в общем-то, эталонный, но для обмена данными с Системой2 используется именно идентификатор Системы2.
Иначе говоря, более сжато, Система1, хоть и является поставщиком информации для других систем, хранит в себе часть информации этих других систем, их идентификаторы. Правильно ли это? Должна ли Система1 вообще знать что-то о существовании папок внутри Системы2? Должна ли знать, что в Системе2 у номенклатуры вообще-то другой идентификатор?
Не является ли более правильным обмен данными по номенклатуре именно по идентификатору Системы1, а Система2 уже внутри себя сама хранит все связи, если ей это надо?
P.S. Как вообще называется вся область архитектурного планирования, связанная с поднятым вопросом?
Это сервисная архитектура, обыкновенная. Нет, они не должны знать друг о друге ничего, кроме внешних контрактов. Поставщик вообще не должен знать ничего о потребителе, а потребитель знает только то что предоставляет поставщик по контракту. Если у них обоих есть что-то общее то оно или выносится в контракт или в отдельный сервис
Дмитрий Петров, там есть варианты. Надо смотреть на детали задачи и что называть соответствием. Если маппинг идентификаторов то вполне, если все данные то только в виде кэша
Иван Шумов, речь только о маппинге идентификаторов.
А что можно почитать об этом? Университетский курс об архитектуре приложений забыл лет десять назад и кто писал об инкапсуляции или сокрытии данных в архитектуре распределенных приложений - не найду.
Дмитрий Петров, я ориентируюсь на чуйку и слушаю голос разума) тут надо смотреть на общую картину с деталями, а это уже вот так на глаз невозможно. Надо смотреть с обеих сторон, понимать что за данные, как их будут использовать (это реально важно)
"Ну конечно, естественно, само собой разумеется - нет!" (Гэндальф в русском переводе).
Эта область называется "инкапсуляция", и это самые азы архитектуры.
Иван Шумов, варианта всего два: или два разных кода знают о потрохах друг друга и полагаются на это знание, а значит, связаны и не могут быть изменены один без другого. Либо им известен только общий формат обмена информацией, и изменения в любом из них могут не затрагивать другой.
Этот общий принцип скрытия внутренних механизмов и данных от внешнего наблюдателя в ООП, например, называется инкапсуляцией (порадуем начетчиков).
Архитектор информационных систем и баз данных. Ful
Теоретически Системе 1 все это безразлично, но информацией лишней редко бывает. Практически в данном случае видимо ситуация в том, что алгоритм синхронизации работает на стороне Источника данных и по каким то причинам в Приемнике собственные идентификаторы. Причины эти тоже желательно понять. Я бы делал алгортим синхронизации на стороне Приемника и использовал стандартные механизма платформы разработки, если они есть.
Эта область называется синхронизация данных.
Дмитрий Петров, Зависит от ситуации. Если данные полностью эквиваленты и система это позволяет, то я бы одни и те же идентификторы использовал. Это потом упростит консолидацию данных в случае необходимости или какой нибудь обмен данными кроме НСИ вдруг понадобиться.
Артемий Прототипы, ну вот для примера - есть другой обмен, по которому Система1 для внутренних отчетов забирает из Системы2 движение номенклатур между складами. Система2 выдает данные по своему идентификатору, т.к. не владеет информацией о том, какой идентификатор у номенклатуры в Системе1.
Простой
Средний
Средний
