我和我的团队正在研究ERP系统有很多模块（人力资源，会计等）
我们面临的问题是，两个模块（HR，Accounting）之间存在一些共享实体，如员工
人力资源系统中的员工有很多细节，如：
Personal Information , Visa Info , Report To , Sources , Training , Etc
会计员工信息很少
Personal Information , Bank Account , Employee Account (That's it )
1）假设每个模块将作为独立版本运行（已完成）
2）假设2个模块将协同工作，这意味着员工将反映在两个模块中，即使每个系统中的流量不同
当我在人力资源模块中定义一名新员工时，我需要什么才能让会计模块感受到变化以及两个模块中发生的操作，他们必须处理同一个实体？
考虑到这个员工与他所关联的公司之间的其他实体有关，并且这两个模块中的公司实体不同（例如，它在人力资源模块中有很多细节，但在会计中只有公司有一些它下的分支机构）
注意：每个模块都有单独的数据库（不想在独立版本中放大数据库）
开发两个模块一起工作的正确方法是什么？或作为独立的???
是否为时已晚，我们应该从头开始设计它作为共享实体？
如果我使用共享实体意味着我应该创建共享业务逻辑和数据访问层？
我尝试谷歌很多关于这一点，但这样的信息只来自真实的实施和生活经验
技术： Asp.net + Mysql
答案 0 :(得分：0)
您可以尝试使用流行的ERP软件（如Oracle Apps或SAP）使用的模型
在Oracle中，所有用户信息都存储在基表（FND_USER）中，并由所有其他模块共享。其他模块可以有额外的表链接到基表。在Oracle Apps中，每个模块都有自己的架构
在现有设计中，如果数据库支持数据库链接，可以尝试使用数据库链接，然后使用触发器更新链接表。
如果你考虑编程的基本原则 - DRY，那么你应该只有一个信息来源。如果可以，请尝试避免同步。
答案 1 :(得分：0)
不要错误地在数据库级别耦合所有模块。
您的模块化设计应包括对象和数据。 User对象应该拥有其数据。需要访问它的所有客户端都应该通过拥有它的对象。
将服务视为对象而不决定它们的部署方式。您可能希望这是一个内存中的对象;它可能是您选择远程使用SOAP或REST或CORBA或XML over HTTP的分布式组件。但重点是 在不共享模式的情况下将问题分解为组件。
如果这样做，您将可以在不影响客户端的情况下更改架构。只有主人需要知道。
当客户端进入数据库时，他们都在数据库级别进行耦合。这可能会导致后来的悲伤。
只是好奇 - 为什么在有这么多商用产品的情况下，你会从头开始编写ERP系统？它们既昂贵又复杂，但编写自己的也是如此。这样的权衡讨论是什么？