ERP系统2个模块之间的集成
我和我的团队正在开发一个有很多模块（人力资源、会计等）的 ERP 系统，
我们面临的问题是两个模块（人力资源、会计）之间存在一些共享实体，例如员工
人力资源系统中的员工有很多详细信息例如：
Personal Information , Visa Info , Report To , Sources , Training , Etc
会计员工的信息很少
Personal Information , Bank Account , Employee Account (That's it )
1）假设每个模块将作为独立版本工作（已完成）
2）假设这两个模块将一起工作，这意味着员工将反映在两个模块中，即使他们在每个模块中具有不同的流程系统
当我在人力资源模块中定义新员工以使会计模块感受到变化以及两个模块中发生的任何操作时，我需要什么，他们必须处理同一实体？
考虑到该员工与其他实体相关，例如与他相关的公司，并且该公司实体在两个模块中都是不同的（例如，它在人力资源模块中有很多详细信息，但在会计模块中，只有公司在其下有一些分支机构） ）
注意：每个模块都有单独的数据库（不想在独立版本中扩大数据库）
开发两个模块协同工作的正确方法是什么？或者作为独立的？？？
是不是太晚了，我们应该从一开始就将其设计为共享实体？
如果我使用共享实体，这意味着我应该共享业务逻辑和数据访问层？
我尝试在谷歌上搜索很多相关信息，但此类信息只能来自真实的实施和生活经验
技术： ASP.NET + MySQL
Me and my team are working on an ERP system have many modules ( HR , Accounting , etc )
The problem we are facing that there are some shared entities between 2 modules (HR , Accounting ) like employees
Employees in HR system have a lot of details like :
Personal Information , Visa Info , Report To , Sources , Training , Etc
Employees in Accounting have few Information
Personal Information , Bank Account , Employee Account (That's it )
1)Suppose each module will work as a standalone version ( this completed )
2)Suppose the 2 modules will work together so that mean the Employees will be reflected in both modules even they have different flow in each system
What i need when i define a new employee in HR module to let the Accounting module feel that change and what ever operation happen in both modules they have to be dealing with the same entity ??
Put in consideration that this employee is related to other entities like the company he is related to and this company entity is different in the both modules (For example it have a lot of detail in HR module but in Accounting only company have some branches under it )
Note: Each Module have separate Database (Didn't want to enlarge the database in standalone version )
What is the right way to develop both modules to work together ?? or as standalone ???
Is it too late and we should design it from the beginning as shared entities ?
And if i used the shared entities that mean i should make shared business logic and data access layer ?
I try to google a lot about this but kind of information like this will come only from real implementation and life experience
Technologies:
Asp.net + Mysql
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以尝试使用 Oracle Apps 或 SAP 等流行 ERP 软件所使用的模型。
在Oracle中，所有用户信息都存储在基表（FND_USER）中并由所有其他模块共享。其他模块可以有链接到基表的额外表。在 Oracle Apps 中，每个模块都有自己的架构
在现有设计中，如果数据库支持，您可以尝试使用数据库链接，然后使用触发器来更新链接表。
如果您考虑编程的基本原则——DRY，那么你应该只有一个信息来源。如果可以的话，尽量避免同步。
You could try using the model used by popular ERP softwares like Oracle Apps or SAP.
In Oracle all user information is stored in base table (FND_USER) and shared by all other modules. The other modules can have extra tables linking to base table. In Oracle Apps each module has its own schema
In your existing design you could try having database links if your database supports it, and then use triggers to update your linked tables.
If you consider the basic principle of programming - DRY, then you should have only one source of information. Try avoiding synchronization if you can.
不要犯在数据库级别耦合所有模块的错误。
您的模块化设计应包括对象和数据。用户对象应该拥有它的数据。所有需要访问它的客户端都应该通过拥有它的对象。
将服务视为对象，而不决定如何部署它们。您可能希望这是一个内存中的对象；它可能是一个分布式组件，您可以选择使用 SOAP、REST、CORBA 或 XML over HTTP 进行远程连接。但重点是
将问题分解为多个组件而不共享架构。
如果您这样做，就可以在不影响客户端的情况下更改模式。只有业主需要知道。
一旦客户端访问数据库，它们就在数据库级别耦合。这可能会导致日后的悲伤。
只是好奇 - 既然有这么多可用的商业 ERP 系统，为什么还要从头开始编写 ERP 系统呢？它们既昂贵又复杂，但自己编写也是如此。权衡讨论是什么样的？
Don't make the mistake of coupling all your modules at the database level.
Your modular design should include both objects and data. A User object should own its data. All clients that need access to it should go through the object that owns it.
Think services as objects without deciding how they are deployed. You may want this to be an in-memory object; it may be a distributed component that you choose to remote to using SOAP or REST or CORBA or XML over HTTP. But the point is
to decompose the problem into components without sharing the schema.
If you do this, you'll make it possible to alter the schema without affecting clients. Only the owner needs to know.
The instant you have clients reaching into the database they're all coupled at the database level. It could lead to grief later on.
Just curious - why would you write an ERP system from scratch when there are so many commercial ones available? They are expensive and complex, but so is writing your own. What was the trade-off discussion like?