2

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

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

4

2 回答 2

4

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

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

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

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

于 2008-10-30T13:14:19.690 回答
1

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

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

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

于 2008-11-04T12:53:48.960 回答