architecture - Best approach to Architect the integration of two separate databases? -

i've ran following questions @ work, , don't have experience or knowledge in order answer them, i'm hoping of wiser folk may able point me in right direction, answers appreciated!

scenario

we have 2 aspects of business using separate databases, human resources , operational areas (homecare).
human resources keep track of company’s employees, shift patterns, absence, pay etc. homecare keeps track of client information, home visits, visit dates , employee/s responsible providing visit.

these 2 systems separate , we’re in process of looking @ ways integrate them.

additionally, we’re looking @ how organise our code looks @ these 2 databases, reusable, organised libraries.

we have 3 applications re-using humanresources.dll, responsible communicating ef 4 object context, contained in library. object context mirror image of database stands.

questions

---

we’re add fourth application use data in hr database.

do we:

create new ef data model, responsible providing information application needs, while duplicating common entities such employee.

or

add new entities/tables large model , accept it’s going large.

---

longer term, need join shift pattern information in hr database client visits on operational areas (homecare) database in 5th application.

we’ve got idea on do; we’ve come following:

create layer sits between humanresources object context , homecare object context, responsible joining 2 sets of data together.

are there other approaches benefit us?

implement facade pattern

a facade adapter complex subsystem. since have 2 subsystems, recommend creating 3 classes following functionalities:

1. humanresourcesfacade : class wraps "human resources" functionality. job of class expose methods perform each unit of work human resources application responsible without exposing information human resources application client.

2. homecarefacade : class wraps "homecare" functionality. job of class expose methods perform each unit of work homecare application responsible for, without exposing information homecare database client.

3. applicationfacade : class wraps both humanresourcesfacade , homecarefacade , provides public methods clients not require knowledge of inner workings of either of 2 nested facades. job of class know: (a) of 2 nested facades responsible each client call, (b) execute client's call of applicationfacade making call appropriate method on nested facade, , (c) translating data received nested facade format usable client , not dependent on data formats of either nested facade.

i recommend using poco object model create common in-code representation of data not dependent upon actual persistence implementation. domain model technique adrian k suggested approach, if not familiar patterns , methodology end being confusing , taking longer techniques more intuitive. alternative use data objects , data mapper. data mapper, takes data data source , turns object not dependent on data source or mapper object. included link below.

one thing clarify while said applicationfacade has 3 jobs, not advising violate single responsibility principle. not mean class needs 3 things itself, should encapsulate whatever mechanism decide use executing process, , no other parts of application should access concerns outside of applicationfacade. example, business objects should not know data source constructed - information should not accessible anywhere other encapsulated applicationfacade class.

reference articles

• martin fowler on application facades
• martin fowler on data mappers
• a free, thorough introduction domain driven design