8

过去，我的项目变得难以管理，尤其是当我必须在几年后重新访问以重做或对某个部分进行重大更新而不必重做所有内容时。这一次，我将重点放在使“可插拔”应用程序设计变得容易和可能，以允许我重新访问和重做一个部分，而无需触及所有内容。

我在想这个结构：

应用程序结构

所以我想要的是能够在有界上下文 2 上工作，并在未来几个月/几年内使用许多新功能扩展它，而有界上下文 1 保持原样。我还将处理 UI，尤其是与限界上下文 2 相关的部分。我还想让用户能够在其他设备上使用限界上下文 2。

最好甚至在有界上下文 2 的 UI 中使用的 Web 技术也会更新，因为这是我们的主要关注领域并且使用最多，因此将其放入自己的 Web UI 项目中并拥有一个“登陆”网站，提供管理用户和让用户登录等常用功能。

现在我正在考虑将所有这些分离到 Visual Studio 中的单独解决方案中以简化管理。但是我可以为每个解决方案创建一个文件夹，然后将所有内容放在那里。

我的问题是推荐的方法是什么，在分成不同的解决方案之前我应该​​考虑什么？

有没有关于如何管理这个的最佳实践？有经验的人吗？

顺便说一句：由于这是由有界上下文划分的，因此系统的各个部分之间需要进行通信，尽管没有直接依赖关系（即上下文 1 管理和维护用于注册员工的业务逻辑，这在上下文 2 中再次需要）。

更新 我意识到需要更多信息。

有界上下文比这两个多。它们都不像一个部门，即员工管理是当他们需要组织/归档与管理他人相关的信息并获得重要事件提醒时的上下文管理器。采购是员工在为一个部门购买商品并进行库存时所处的环境，可能有 20-40 个组织部门使用它。我正在考虑“报告”是否是一个单独的有界上下文（尽管没有非常有趣的逻辑和行为）。这些往往从提供基本功能的小规模开始，然后随着更多功能的添加和人们“发现”新的需求而增长。它们是单独更新的，我希望它们中的一些能够及时成长为更大的系统，即使它们开始解决相当基本的需求。

4

3 回答 3

2

因此，您有一堆代码，并且希望在不加载与其他部分相关的项目的情况下处理代码的某些部分。那么是的，您可以将每个部分作为单独的 Visual Studio解决方案。

关键是 VS 解决方案只是一个 [.sln] 文件，描述了该解决方案对哪些项目进行分组。不要仅为此目的制作项目的单独副本。您必须只维护所有项目一次（每个副本一份），然后创建单独的解决方案并包含您认为与此解决方案相关的项目（代码的这一部分）。

例如，您可能会认为“员工管理”是一个仅包含 3 个（总共 40 个）项目的解决方案。然后您继续创建一个包含这三个项目的解决方案。可能您最终会拥有单独的较小解决方案，以便与其他解决方案分开工作。

您不妨考虑拥有一个包含所有项目的大型解决方案（同样，每个项目只有一个实例，但可以是多个解决方案的一部分）。这种大解决方案可能对构建/发布准备等主要操作很有用。

我怀疑您是在试图夸大解决方案的重要性。实际上，您拥有的所有代码都是一个巨大的统一体，因为它们相互引用并且如果不[重新]编译其他代码就无法构建。即使您可能会尝试提出以某种方式与您的业务需求相对应的解决方案结构，但它似乎仍然是与解决方案无关的问题的另一个方向。这可能类似于解决划分为程序集、动态加载和可扩展性等问题。

结论：根据您在使用源代码时想要实现的便利性将代码拆分为解决方案，因为这只是将源代码划分为子部分，仅此而已。

编辑/添加：

您也可以决定将解决方案拆分为独立的解决方案，但这是不同的。这意味着解决方案项目只能引用其他解决方案中其他项目的输出（dll、exe）文件。当每个解决方案都将另一个解决方案视为 3-rd 方代码（没有直接的项目引用，但只有输出引用）时，可以做到这一点。

于 2012-11-23T18:58:29.410 回答
1

我认为在决定是否应该有多个解决方案时，答案是您是否真的设想在其他不同应用程序中使用构成有界上下文的一个（或多个）程序集，这将暴露所有完全相同的用途您的有界上下文管理的情况。如果是这种情况，那么单独的解决方案是有意义的。但是，如果您的所有 UI 层在概念上都是同时发布的同一个应用程序，那么我会将其保留在一个解决方案中，除非您的项目太多以至于 Visual Studio 变得无法使用。

不过，如果您真的要让另一个应用程序使用相同的有界上下文，我会感到惊讶。如果您考虑一下，您是否希望仅将更新版本的逻辑部署到您的 Web 服务，而不是您的 Windows 窗体应用程序？可能不会，因为逻辑更改可能会引入奇怪的问题，其中数据不是应用程序所期望的。

您所拥有的听起来像是一个平台，并且该平台的所有部分（UI 层）都应该运行完全相同的逻辑。

于 2012-11-23T17:56:35.633 回答
1

解决方案的观点不是我猜的主要问题。我会选择在文件夹中组织我的项目。每个有界上下文一个，Web UI 在另一个有界上下文中（如果考虑的话，它可以被认为是它自己的一个有界上下文）。

您可能有一些共享内核，由您的所有 bc 共享，您也可能将其放在不同的文件夹中。

通常每个 bc 应该是独立的（共享程序集除外），并且您的 UI 应该通过它们的接口只知道 bc（例如 WCF 合同）

全局解决方案可能包含 (MyApplicationName.sln) 中的每个文件夹和项目，但您可以考虑仅在部分解决方案上工作的专用解决方案，例如 MyApplication_BCName 仅包含 bc 文件夹、共享程序集和 UI（如果适合）您的需求，并且您不希望有一个庞大的解决方案来处理。

从小事做起，在真正需要时尽快做事。要特别注意交叉引用，在 vs 中设置的方式实际上并不重要。如果程序集是松耦合的，那么您可以在以后随时按照您想要的方式重新排列它们。

我不是一流的程序员，我只是碰巧认为这样的事情对于我参与的最新项目来说似乎很好，它可能会在几个月内完全改变（几个小时..??;)）

于 2012-11-23T18:29:25.770 回答