I work in an intranet team that develop customized solution for my current company, its parent company and its subsidiaries. Needless to say, most of the time we found that we need similar domain objects such as Projects, Tenders, Contracts, Users / Employees, etc. across multiple application development projects. Of course, one thing that comes to mind is "Hmm... it would be great if we can pull all of these common domain objects from a single source to avoid duplication."

But... wait, it's not as simple as that.

Each application might not be used across all of the intranets. For example, application 1 is being built for subsidiary A, application 2 is being built for subsidiary B. The companies sometime are not even in the same country.

The easy way out: why the heck bother with a single source, just let each application has its own domain objects, even if it is similar in nature (application 1 has its own project domain, application 2 has its own project domain, etc.). Completely independent of each other. Nothing wrong with that, right?

Until... subsidiary B has a chance to look at the ...say... Leave Request application that is being used at subsidiary A and decided they want to use it too, but with some modifications to fit its own requirements. *Smack head* DOH... now what... well, again going with the simplest solution / hack that comes to mind... let's separate the database, tweak the application a bit, save it as LeaveRequestSubsidaryB, and there you have it. Nothing wrong with that, right?

Until... parent company (enterprise level) decided that all of these data should be integrated to make such and such big report / KPI on employee attendance or blah blah blah. You get the idea... Now what? *Scratch head* Uhm... create a common data container for all the different LeaveRequestXXX application, extract data from each of these apps and produce report on the common data? Well, that's one way to go. I am sure there are others.

The point of this long winding rambling is, well, this common data thing is bugging me. It keeps popping up no matter what. Why don't we just create one that can be shared across the enterprise? But, do we even have the time to do this first? We will certainly have to take into account all of the complexities of requirements from different applications and design it appropriately. That takes time. A LOT OF TIME.

Meanwhile, management keep asking when is application A going to be completed? What about application B, and so on... push push push ***ARRGHH! head is about to explode***

How can we move along different projects without having to wait for this "common domain object library" to be finished first?

Well... I gave this some thought and this is far from perfect, but here they are anyhow:

1. Dependency Inversion comes to mind. What if we can find some common interfaces for these common objects and code against that the interface instead for common functions.
2. Plug-in framework comes to mind. Replaceable domain object assembly that will allow each project to move along independently even without the common library to be completed.
3. Extensible domain object through inheritance / company specific domain interface

Well, playing around with the idea, I managed to build a working prototype of point 1 and 2 so far. The hard part is designing the real interfaces. What are going to be the abstracted methods for such interfaces? I am starting with the simplest stuffs for now, for example, getting a list of Project to populate a dropdown list / lookup. That should be common enough across multiple application. There will be other more specific methods, but enough for now.

So, what do you think? Is such thing achievable? Or should we just give up on it and go w/ separate app for separate subsidiary, and reconsolidate the data when necessary?