Question

这是一个高级别的项目组织问题。

组织包含许多子应用程序的项目/解决方案（Visual Studio）的“正确”方法是什么？

这必须是大型企业级项目中的常见问题。任何人都可以指向白皮书/书籍/链接，以帮助决定如何构建它？

在24小时内学习企业架构是完美的，但似乎并不存在。

我们的第一次尝试遵循3层服务架构，但除了通用业务功能（ProcessOrder（..），BalanceAccount（..）等），我们还需要特定于应用程序的数据。

遵循n层架构，所有应用程序仍需要通过BLL - ＆gt; DLL获取任何信息（ViewModel，特定于应用程序的数据）。

某些模型类（BOM）通用性足以在整个过程中使用（订单，账单，账户，客户等）

一种选择是将所有业务实体集中在同一个Enterprise.BOM项目下，并具有多个名称空间 - 一些是全局的，一些是ViewModel类的特定应用程序。

然后BLL和DAL层将遵循相同的组织 - 每个应用程序都有自己的命名空间，并且在任何地方使用的东西都放在根命名空间。

但随着应用程序数量的增长，重用现有对象/进程将是一项挑战（即每个应用程序可能需要对Bill信息执行某些操作，但不应定义自己的Bill类，而是使用BLL中的现有类/ DAL）。

从顶部强制要求的另一个方向是以SOA-izable方式开发所有内容：“应用程序”通过BLL中定义的所有流程 - 业务逻辑有效地成为视图/工作流程，因此“应用程序”（基本上UI）可以替换为服务层，以向外部系统公开功能。

如果相关，我们是一个带有规则引擎的.NET商店，但是没有工作流程（尽管可能在一两年内，因此未来的WS集成很重要）。

提前致谢！

Answer 1

24小时学习企业架构将是完美的

即使确实存在，我也不会相信它。请记住，没有一种真正的方法来构建企业。在任何情况下，没有一种模式比其他模式更好。您的企业将找到自己的方式。会有折衷，会有妥协等等。有些事情对开发人员有意义，有些事情对用户有意义，有些事情对管理有意义......但一切应该对业务有意义。

话虽如此，请在这里采取任何建议。

组织代码时，一个好的经验法则是问自己“这个代码是什么？”也就是说，对于你正在编写的任何内容，整个系统的哪个部分关心它？这就是代码所属的地方。如果它是指定某些UI行为的代码，则它不属于DAL。如果它是维护核心业务逻辑的代码，则它不属于UI。等等。

一种对我有用的方法是Domain Driven Design。作为一个过程，我倾向于这样做：

定义商业模式。这是一切应该对大多数人最有意义的地方。这是你的“无所不在的语言”。公司里的每个人都知道Order是什么。他们都知道当你在Order.Submit()上打电话时会发生什么。这是你的BLL，它所关心的只是业务逻辑。应该没有UI问题，没有数据持久性问题，没有任何类似问题。这是定义业务逻辑的核心程序集，可以在域中的任何应用程序中重复使用。
定义数据持久性。这是您的业务模型与数据库相遇的地方。它可以是一个数据库，多个数据库，数据库/文件系统/服务等的混合，等等。（现在，真正的持久性无知是域驱动设计的圣杯。你的模型可能必须为你的基础设施做出一些妥协。它会发生。）
定义您的应用程序。这些可以是用户界面，Web服务等。从域核心的角度来看，这无关紧要。业务逻辑是业务逻辑，无论使用什么，它都在整个域中维护。如果特定应用程序需要以特定方式覆盖业务逻辑，请在应用程序中执行此操作。向用户呈现数据，从用户收集数据，这就是应用程序关心的内容。

现在，一些应用程序将希望使用更多自定义对象。也许一个应用程序想要使用Order类，但以某种方式重新塑造它。甚至可能将它与其他课程结合起来。这可以。这是该应用程序的一个问题。在内部，它将拥有自己的迷你域，在其中定义其自定义模型，并具有自己的自定义DAL，以将这些模型转换为核心域模型。这将更像是一个“ViewModel”，因为它完全属于该应用程序，而不属于业务逻辑。

将每个应用程序视为微型域。从整个域的角度来看，每个应用程序都是UI的一部分。从应用程序本身的角度来看，整个域是应用程序持久性背后的基础架构。

因此，一般来说，您可能会看到我的Visual Studio项目组织如下：

Project: MyBusiness.Domain
  Folder: Models
  Folder: Services
  Folder: Repositories
Project: MyBusiness.Infrastructure.DAL
  Reference: MyBusiness.Domain
  Folder: Repositories
Project: MyBusiness.Infrastructure.AddressService
  Reference: MyBusiness.Domain
  Folder: Services
Project: MyBusiness.Application.Intranet
  Reference: MyBusiness.Domain
  Folder: Controllers
  Folder: Views
  Folder: ViewModels
Project: MyBusiness.Application.CustomerIntegrationService
  Reference: MyBusiness.Domain
  Folder: ServiceDTOs

等等。我使用IoC容器（StructureMap是我个人最喜欢的容器，但还有很多其他容器）用于连接依赖项。除了Models之外，Domain项目中的几乎所有内容都只是一个接口。可以有多个基础设施项目实现这些接口，每个应用程序项目可以配置在连接IoC容器时要使用哪些接口。

这种方法可以将问题完全分开。您可以根据需要使用域核心的任意数量的应用程序，并且可以根据需要拥有尽可能多的依赖项实现（包括测试模拟实现）。

我希望这有所帮助，并且最终不会在某些切线上结束。我承认，要准确描述你在问题中提出的问题有点困难。

ViewModel / Business Logic的企业架构

1 个答案: