设计模式或代码异味，由于功能分解而导致规范化的数据 [英] Design pattern or code smell, denormalised data as a result of functional decomposition

问题描述

我是 http://highscalability.com/ 的忠实拥护者，开发，以便沿着功能边界分解我的应用程序，以此作为扩展服务器端（尤其是数据库层）的途径。这涉及在服务器上实现应用程序的不同功能组件（我们可以使用几个单独的模块供客户使用）作为自己独立的应用程序，与服务器联系的客户端知道需要针对不同数据联系的不同服务，因此统一的视图呈现给用户。
问题出现在不同组件中的数据之间存在链接时，即一个组件拥有所有用户数据，而另一个组件则需要引用用户作为某些数据的所有者。我目前正在通过保留链接每一侧的主键信息来完成此操作（就像它们都生活在单个数据库中一样），但是此链接表必须同时存在于两个组件中，以允许在其中进行查找任一个方向，即获取特定用户拥有的东西和获取特定用户的拥有者将各自使用不同的组件。替代方法是将链接数据仅存储在一个组件中，但是反向查找将需要2个调用而不是一个调用。

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?

推荐答案

功能性分解是一种错误的设计策略。

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.

这篇关于设计模式或代码异味，由于功能分解而导致规范化的数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！