设计模式或代码异味，由于功能分解而导致的非规范化数据

Question

我是http://highscalability.com/ 的忠实粉丝，并且一直在研究我当前的开发，以沿着功能边界分解我的应用程序，以此作为能够横向扩展服务器端，特别是数据库层的途径。这涉及将应用程序的不同功能组件（我们有几个客户可以使用的单独模块）实现为服务器上自己的独立应用程序，与服务器联系的客户端知道它需要为不同的数据联系的不同服务，因此统一的视图呈现给用户。 当不同组件中的数据之间存在链接时，问题就出现了，即一个组件保存所有用户数据，但另一个组件需要引用用户作为某条数据的所有者。我目前通过保存链接每一侧的主键信息来做到这一点（就像它们都住在一个数据库中一样），但是这个链接表需要存在于两个组件中以允许在任一方向，即“获取特定用户拥有的东西”和“获取该特定事物的所有者”都将使用不同的组件。对此的替代方法是将链接数据仅存储在一个组件中，但反向查找将需要 2 次调用，而不仅仅是 1 次。

我的问题是，这些链接表的重复是我应该避免的某种代码异味，还是当您按照这样的功能线拆分应用程序时，事情就是这样？

Answer 1

功能分解是一种糟糕的设计策略。

考虑尝试使用功能分解构建厨房搅拌机。要搅打、混合、搅拌和混合，您需要四个碗、四个电机、四个刀片、四个开关、四个电源和四个底座来容纳每个“功能”。

功能分解用于需求分析。不是为了设计。

分析通过后，您必须进行综合通过，以组装通用组件、通用框架元素和通用数据模型。您应该最终得到一个支持多种功能的数据模型。

Answer 2

我认为这取决于 - SOA 基本上不意味着功能分解吗？

问题是当不同的功能需要访问相同的数据时，这可能是一种错误的气味。也许需要另一个函数来处理对公共数据的访问，或者函数分解在这种情况下是错误的答案。

如果您想将厨房扩大到食品制造厂，那么使用单独的大桶进行搅打、搅拌和混合可能是有意义的，并带有大桶“订阅”的某种管道（或“总线”）要，但对于国内搅拌机来说，重复使用同一个碗并具有可切换的附件会更有意义。