为什么要将BizTalk解决方案拆分为多个项目

我已经阅读了将BizTalk解决方案拆分为多个项目的良好实践，并且看到了关于拆分的确切性质的一些争论，例如。。。
-可以按工件分割，即模式、编排、映射等。
-可以按功能划分

---

但是/con的好处是什么呢？

BizTalk解决方案通常包括模式、映射和编排。解决方案还可以包括支持组件、业务规则、基于端口的路由和转换的定义、贸易伙伴以及其他几种类型的工件

有效地管理所有这些工件有很多好处——好处远远多于缺点

这些好处包括：

• 基于 工件的逻辑分组（按 的功能或工件类型 示例）。这种方法降低了成本 修改以下方面的可能性： 您的解决方案与 你现在正在研究的问题 时间
• 更易于测试–您可以编译和 只部署您需要的组件 修改
• 更容易在一群人之间分配工作 开发者
• 解决方案启动时更易于管理 变得更大–可能需要几个小时 加载大型BizTalk的分钟数 VisualStudio中的解决方案
• 支持更高级的方法 与ESB风格的解决方案相关（非常 松耦合）。取决于你的 总体方法，您可以创建一个 非常模块化的解决方案 模块可以运行的点 并完全更新 彼此独立
• 使之有可能更新版本 人工制品分开
• 促进更细粒度的控制 安全性和内存利用率过高 通过将相关功能分组，例如 为特定的应用程序部署它们 例如，主机实例（您可以 还可以管理细粒度的.NET 安全策略比 您可以使用部署 一些组件）

在调试解决方案时，将解决方案拆分为多个项目或解决方案的主要缺点在于。对于许多刚接触BizTalk的开发人员来说，调试BizTalk解决方案并不简单，必须缩小解决方案中的错误范围并不能使这项工作变得更容易。但是，您可以通过更有效地安排解决方案并使用有关命名、目录结构、名称空间的安排和相关方法的标准来管理此问题，从而更容易地找到查找的位置

其他缺点包括：

• 更多要签名和部署的程序集 进入GAC
• 相互依赖 项目可能导致部署 可能难以纠正的错误 在组织不良的地方追踪 解决方案

您应该在项目开始时（理想情况下是在设计期间）花一些时间来设置解决方案的基本组织。不存在“一刀切”的方法—您需要考虑在开发、部署和维护期间，在解决方案提供给您的组织或客户的功能的上下文中，您希望如何管理解决方案

---

一个好的起点是根据工件类型或功能区域划分解决方案。随着解决方案的发展，您将更好地了解工件之间的关系，以及您希望如何管理强命名、安全性和物理部署，从而更好地安排解决方案。您需要小心使用这种方法，因为您可能最终不得不重新安排解决方案的大部分内容，如果您的项目时间紧迫，这可能会造成中断。

感谢Erik的全面回复，非常感谢