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:

http://stackoverflow.com/questions/4019902/soa-joining-data-across-multiple-services

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?

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:

https://stackoverflow.com/questions/4019902/soa-joining-data-across-multiple-services

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?

I have recently been readinh Hohpe and Woolfe's Enterprise Integration Patterns, some of Thomas Erl's books on SOA and watching various videos and podcasts by Udi Dahan and co on CQRS and Event Drivent 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 across 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 propogated 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:

http://stackoverflow.com/questions/4019902/soa-joining-data-across-multiple-services

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, and application etc?

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:

http://stackoverflow.com/questions/4019902/soa-joining-data-across-multiple-services

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?