我是http://highscalability.com/的忠实粉丝，我一直在寻找当前的开发，将我的应用程序沿着功能边界分解为能够扩展服务器端，特别是数据库层的途径。这涉及到实现应用程序的不同功能组件（我们有几个客户可以使用的独立模块）作为他们自己在服务器上的独立应用程序，联系服务器的客户端知道它需要联系的不同服务，以便不同的数据向用户呈现统一视图。 当不同组件中的数据之间存在链接时，问题就出现了，即一个组件保存所有用户数据，而另一个组件需要引用用户作为某个数据的所有者。我目前正在通过保存链接每一侧的主键信息来实现这一点（就像它们都存在于单个数据库中一样），但是这个链接表需要存在于两个组件中以允许在任何一个方向，即“获取特定用户拥有的东西”和“获得这个特定事物的所有者”将各自使用不同的组件。另一种方法是将链接数据仅存储在其中一个组件中，但反向查找则需要2个调用而不是一个。
我的问题是，这些链接表的重复是某些代码味道我应该避免的，或者这就是你按照这样的功能划分应用程序的方式吗？
答案 0 :(得分：3)
功能性分解是一种糟糕的设计策略。
考虑尝试使用功能性分解来构建厨房搅拌机。为了鞭打，混合，搅拌和混合，你有四个碗，四个电机，四个刀片，四个开关，四个电源和四个底座来保持每个“功能”。
功能分解用于分析需求。它不适合设计。
在分析完成后，您必须进行综合传递以组合通用组件，通用框架元素和通用数据模型。您应该使用支持多种功能的单一数据模型。
答案 1 :(得分：1)
我认为这取决于 - SOA基本上不代表功能分解吗？
问题是当不同的功能需要访问相同的数据时，这可能是一种有些错误的气味。也许需要有另一个函数来处理对公共数据的访问，或者在这种情况下，函数分解可能是错误的答案。
如果您正在尝试将厨房扩展到食品生产厂，那么可能需要使用单独的大桶进行搅打，搅拌和混合，以及大桶“订购”的某种管道（或“公共汽车”）但是对于一个健美的搅拌器来说，重复使用同一个碗并具有可切换的附件会更有意义。