Design pattern or code smell, denormalised data as a result of functional decomposition

Question

I'm a big fan of http://highscalability.com/ and have been looking in my current development to decompose my application along functional boundaries as a route to being able to scale out the server side, specifically the database layer. What this involves is implementing different functional components of the application (we have several separate modules customers can use) as their own independent application on the server, the client which contacts the server is aware of the distinct services it needs to contact for different data so a unified view is presented to the users. The problem comes when there are links between the data in different components, ie one component holds all the user data, but another needs to reference a user as being an owner of some piece of data. I'm currently doing this by holding the primary key information for each side of the the link (as you would if they all lived in a single database), but this link table needs to exist in both components to allow lookups to be done in either direction, ie 'get the things a specific user owns' and 'get the owners of this specific thing' would each use different components. The alternative to this would be to store the link data in only one of the components, but then the reverse lookups would require 2 calls instead of just one.

My question is this, is the duplication of these link tables some kind of code smell I should be avoiding or is this just the way things go when you split your app along functional lines like this?

Answer 1

Functional decomp is a bad design strategy.

Think of trying to build a kitchen blender using functional decomp. To whip, mix, stir and blend, you'd have four bowls, four motors, four blades, four switches, four power supplies and four bases to hold each "function".

Functional decomp is for analysis of requirements. It isn't for design.

After your analysis pass you have to do a synthesis pass to assemble common components, common framework elements, and a common data model. You should wind up with a single data model supporting multiple functions.

Answer 2

I think it depends - doesn't SOA basically mean functional decomp.?

Problem is when different functions need access to the same data, that probably is a smell that somethings wrong. Perhaps there needs to be another function to handle access to the common data, or perhaps functionl decomposition is the wrong answer in this case.

If you were trying to scale a kitchen up to a food manufacturing plant then it might make sense to have separate vats for whipping, stirring and blending, with some sort of pipeline (or 'bus') that the vats "subscribe" to, but for a doesmetic blender it would make more sense to reuse the same bowl and have switchable attachments.