Интеграция между двумя модулями в системе ERP

Question

Я и моя команда работаем над ERP-системой, в которой много модулей (HR, бухгалтерия и т. Д.)

Проблема, с которой мы сталкиваемся, состоит в том, что между двумя модулями (HR, бухгалтерия) есть несколько общих сущностей, таких как сотрудники

Сотрудники в системе управления персоналом имеют много деталей, таких как:

Personal Information , Visa Info , Report To  , Sources , Training , Etc 

Сотрудники в бухгалтерии имеют мало информации

Personal Information , Bank Account , Employee Account (That's it )

1) Предположим, что каждый модуль будет работать как отдельная версия (это завершено)

2) Предположим, что 2 модуля будут работать вместе, поэтому сотрудники будут отражаться в обоих модулях, даже если у них разные потоки в каждой системе

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

Учтите, что этот сотрудник связан с другими субъектами, такими как компания, с которой он связан, и эта сущность компании отличается в обоих модулях (например, он содержит много деталей в модуле управления персоналом, но в бухгалтерском учете некоторые компании имеют ветки под ним)

Примечание: Каждый модуль имеет отдельную базу данных (не хотел расширять базу данных в автономной версии)

Как правильно разработать оба модуля для совместной работы? или как автономный ???

Не слишком ли поздно, и мы должны с самого начала спроектировать его как общие объекты?

А если я использовал общие объекты, это значит, что я должен создать общую бизнес-логику и уровень доступа к данным?

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

Технологии: Asp.net + Mysql

Answer 1

Не делайте ошибку, связывая все ваши модули на уровне базы данных.

Ваш модульный дизайн должен включать как объекты, так и данные. Пользовательский объект должен владеть своими данными. Все клиенты, которым необходим доступ к нему, должны пройти через объект, которому он принадлежит.

Думайте о сервисах как об объектах, не решая, как они развернуты. Вы можете захотеть, чтобы это был объект в памяти; это может быть распределенный компонент, который вы выбираете для удаленного использования SOAP, REST, CORBA или XML через HTTP. Но дело в том, разложить проблему на компоненты без совместного использования схемы.

Если вы сделаете это, вы сможете изменить схему, не затрагивая клиентов. Только владелец должен знать.

В тот момент, когда клиенты попадают в базу данных, все они связаны на уровне базы данных. Это может привести к горе позже.

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

Answer 2

Вы можете попробовать использовать модель, используемую в популярных программах ERP, таких как Oracle Apps или SAP.
В Oracle вся пользовательская информация хранится в базовой таблице (FND_USER) и используется всеми другими модулями. Другие модули могут иметь дополнительные таблицы, связанные с базовой таблицей. В Oracle Apps каждый модуль имеет свою собственную схему

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

Если вы считаете основной принцип программирования - СУХОЙ, то у вас должен быть только один источник информации. Старайтесь избегать синхронизации, если можете.