Integration between 2 modules in ERP system

Question

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

Thanks in advance

Answer 1

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.

Answer 2

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?