Design patterns 设计模式或代码气味，功能分解后的非规范化数据

我是一个超级粉丝，在我目前的开发中，我一直在寻找沿着功能边界分解我的应用程序的方法，以此来扩展服务器端，特别是数据库层。这涉及到在服务器上实现应用程序的不同功能组件（我们有几个客户可以使用的单独模块）作为他们自己的独立应用程序，与服务器联系的客户机知道它需要为不同数据联系的不同服务，因此向用户提供了一个统一的视图。 当不同组件中的数据之间存在链接时就会出现问题，即一个组件保存所有用户数据，而另一个组件需要引用某个用户作为某个数据段的所有者。目前，我通过保存链接两侧的主键信息来实现这一点（若它们都位于一个数据库中，您会这样做），但这个链接表需要存在于两个组件中，以允许在任意方向进行查找，ie“获取特定用户拥有的物品”和“获取特定物品的所有者”将分别使用不同的组件。替代方法是只在一个组件中存储链接数据，但是反向查找将需要两个调用，而不是一个调用

---

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

功能性反编译是一种糟糕的设计策略

考虑一下尝试使用函数式分解构建厨房搅拌机。要搅拌、混合、搅拌和混合，你需要有四个碗、四个马达、四个刀片、四个开关、四个电源和四个底座来容纳每个“功能”

功能性反编译用于分析需求。这不是为了设计

---

在您的分析过程之后，您必须执行一个综合过程来组装公共组件、公共框架元素和公共数据模型。您应该得到一个支持多个功能的单一数据模型

我认为这要看情况而定——SOA基本上不是指功能性的反编译吗

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

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