Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have recently been reading Hohpe and Woolf's Enterprise Integration Patterns, some of Thomas Erl's books on SOA and watching various videos and podcasts by Udi Dahan et al. on CQRS and Event Driven systems.

Systems in my place of work suffer from high coupling. Although each system theoretically has its own database, there is a lot of joining between them. In practice this means there is one huge database that all systems use. For example, there is one table of customer data.

Much of what I've read seems to suggest denormalising data so that each system uses only its database, and any updates to one system are propagated to all the others using messaging.

I thought this was one of the ways of enforcing the boundaries in SOA - each service should have its own database, but then I read this:


and it suggests this is the wrong thing to do.

Segregating the databases does seem like a good way of decoupling systems, but now I'm a bit confused. Is this a good route to take? Is it ever recommended that you should segregate a database on, say an SOA service, an DDD Bounded context, an application, etc?

share|improve this question
The original question you link is wrong. The question itself is wrong, as most of the answers elude to. SOA is not about splitting a single application into discrete services and partitioning their data. –  Jeremy Oct 24 '11 at 18:04
I understand the question is wrong, It was the answers that made me reevaluate my thinking. –  Paul T Davies Oct 24 '11 at 21:38
I think the services must be coupled –  B Seven Dec 3 at 14:54

4 Answers 4

up vote 8 down vote accepted

Decoupling only works if there really is separation. Consider if you have an ordering system:

  • Table: CUSTOMER
  • Table: ORDER

If that's all you've got, there's no reason to decouple them. On the other hand, if you have this:

  • Table: CUSTOMER
  • Table: ORDER

Then you could argue that ORDER and CUSTOMER_NEWSLETTER are part of two totally separate modules (ordering and marketing). Perhaps it makes sense to move these into separate databases (one for each table), and have both modules share access to the common CUSTOMER table in its own database.

By doing that you're simplifying each module, but you're increasing the complexity of your data layer. As your application grows larger and larger, I can see an advantage to separating. There will be more and more "data islands" that really have no relation to each other. However, there will always be some data that cross-cuts all modules.

The decision to put them in different physical databases would typically be based around real-world constraints like frequency of backups, security restrictions, replication to different geographic locations, etc. I wouldn't separate tables into different physical databases just because of separating concerns. That can be handled more simply with different schemas or views.

share|improve this answer
-1. They should only be in seperate databases if there is a reason to put them there. You need to "get something out of it" because it certainly makes your app more complex. –  scottschulthess Mar 27 '12 at 19:41
I think its worth putting emphasis on the importance of separating the two areas of functionality at the data layer (whether using separate schema's or something else). Each module should only access the data of the other module through the other module's API - this is similar to OO principles of encapsulation. I.e. don't share a schema between multiple modules. Also, I would recommend against views, instead preferring to expose data via. an API. –  SHC Feb 5 at 15:03

Where I work we have an ESB to which 6 different applications (or should I say "endpoints") are connected. Those 6 applications work with 3 different Oracle schemas on 2 database instances. Some of these applications coexist in the same schema not because they are related but because our database infrastructure is managed by an external provider and obtaining a new schema just takes forever (also, we don't have DBA access of course)... It really takes so long that at one point we thought of reusing an existing schema "temporarily" to be able to continue development. To enforce "separation" of data, table names are prefixed, for example "CST_" for customer. Also, we have to work with a schema that for some valid reasons we cannot absolute change... It's strange I know. Of course, as it always happens, "temporarily" has changed into "temporar-namently" if you know what I mean ;-)

Our different applications connect to their respective database schema and work with their own PL/SQL packages and we absolutely forbid ourselves to interact directly with tables/data that is outside our application domain.

When one of the application connected to the ESB needs information outside from its domain, it calls the related service on the ESB to obtain the data, even if that information is in fact in the same schema, requiring in theory just a little join statement in one of the SQL requests.

We do that in order to be able to split our application domain into different schemas/databases, and in order for the services on the ESB to still work properly when it happens (it's Christmas soon, we're corssing fingers)

Now, this may look strange and awful from the outside but there are reasons to that and I just wanted to share this concrete experience to show you that one or more databases is not that important. Wait, it is !, for many reasons (+1 for Scott Whitlock, see last paragraph about backup and such that mya lead you into trouble) But it is equally important I think to have your SOA services being properly designed, at least that is my opinion, and I'm not a DBA. Ultimately, all your databases belong to your "enterprise datawarehouse", right?

Finally, I won't rephrase Scott Whitlock's last paragraph, particularly this

I wouldn't separate tables into different physical databases just because of separating concerns.

is really super important. Don't do it if there is no reason.

share|improve this answer

Decoupling databases and keeping the data consistent between them is an expert level task. It is very easy to get wrong and end up with the problems of duplicates etc, that the current system is designed to avoid. Frankly, taking a working system and doing this is pretty much a guarantee of introducing new bugs for no real value to the users.

share|improve this answer

I've seen the worst possible nightmares in software architecture due to data integration, and the best weapon against this type of mess that I've encountered so far id DDD-Style Bounded Contexts. Which is not very far away from "SOA done right", on a certain sense.

However, data itself is not the best way to attack the problem. One should focus on the expected/needed behavior and bring the data where it matters. We might end up having some duplication this way, but this is not normally an issue compared with the blocks to system evolution almost always associated with data-integrated architectures.

To put it simple: if you are looking for loosely coupled systems, don't stay coupled on the data. Go for weel encapsulated systems and a well-structured communication channel in between, acting as "lingua franca".

share|improve this answer
And ...answering straight to the title question: "Yes, I'd consider it a risky practice to share a database in a SOA", If it looks like the most reasonable thing to do, there's probably some serious design flaw. –  ZioBrando Nov 12 '11 at 16:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.