ERP系统中两个模块的集成
我和我的团队正在开发一个ERP系统，有很多模块(人力资源、会计等)
我们面临的问题是两个模块(人力资源、会计)之间有一些共享实体，比如员工
人力资源系统中的员工有很多细节，比如：
Personal Information , Visa Info , Report To , Sources , Training , Etc 会计从业人员信息少
Personal Information , Bank Account , Employee Account (That's it )1)假设每个模块将作为独立版本工作(此版本已完成)
2)假设这两个模块协同工作，这意味着员工将在两个模块中得到反映，即使他们在每个系统中都有不同的流程。
当我在人力资源模块中定义一名新员工时，我需要什么让会计模块感觉到变化，以及在这两个模块中发生了什么操作，它们必须处理同一个实体?？
考虑到该员工与他所关联的公司等其他实体有关，该公司实体在这两个模块中都有差异(例如，在人力资源模块中有很多详细信息，但在会计部门中只有公司有一些分支)
注意：每个模块都有单独的数据库(不想在独立版本中扩展数据库)
开发这两个模块以协同工作的正确方法是什么？还是作为独立的？
现在是不是太晚了，我们应该从一开始就把它设计成共享的实体？
如果我使用共享实体，这意味着我应该创建共享业务逻辑和数据访问层？
我试着在谷歌上搜索很多这方面的信息，但是像这样的信息只能来自实际的实现和生活体验。
技术： Asp.net + Mysql
回答 2
Stack Overflow用户
发布于 2010-02-18 11:16:11
您可以尝试使用流行的ERP软件(如Oracle应用程序或SAP )所使用的模型。
在Oracle中，所有用户信息都存储在基表(FND_USER)中，并由所有其他模块共享。其他模块可以有额外的表链接到基表。在Oracle应用程序中，每个模块都有自己的模式
在现有设计中，如果数据库支持数据库链接，则可以尝试拥有数据库链接，然后使用触发器更新链接的表。
如果你考虑编程的基本原理--干法，那么你应该只有一个信息源。如果可能的话，尽量避免同步。
Stack Overflow用户
发布于 2010-02-28 15:10:47
不要犯在数据库级别上耦合所有模块的错误。
您的模块化设计应该包括对象和数据。用户对象应该拥有它的数据。所有需要访问它的客户端都应该通过拥有它的对象。
在没有决定如何部署服务的情况下，将服务视为对象。您可能希望这是一个内存中的对象；它可能是一个分布式组件，您可以选择远程使用SOAP或REST，或者通过HTTP使用CORBA或XML。但关键是将问题分解为组件，而不共享模式。
如果这样做，就可以在不影响客户端的情况下更改模式。只有主人才需要知道。
当客户端到达数据库时，它们都是在数据库级别上耦合的。这可能会导致日后的悲痛。
只是好奇--当有那么多商业系统可用时，你为什么要从头开始编写ERP系统呢？它们既昂贵又复杂，但你自己的写作也是如此。交换的讨论是什么样的？
https://stackoverflow.com/questions/2288051
复制相似问题
腾讯云开发者
