ViewModel/Business Logic的企业架构

Question

这是一个高级项目组织问题.

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

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

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

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

遵循n层架构,所有应用程序仍然需要通过BLL - > DLL来获取任何信息(ViewModel,特定于应用程序的数据).

一些模型类(BOM)是通用的,可以在整个过程中使用(订单,账单,账户,客户等)

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

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

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

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

如果相关,我们是一个带有规则引擎的.NET商店,但是没有工作流程(虽然它可能在一两年内,因此未来的WS集成很重要).

提前致谢!

Answer 1

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

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

话虽这么说,在这里采取任何建议与一粒盐.

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

一种对我有用的方法是域驱动设计.作为一个过程,我倾向于这样做:

1. 定义业务模型.这是一切应该对大多数人最有意义的地方.这是你的"无所不在的语言".公司里的每个人都知道这Order是什么.他们都知道当你打电话时会发生什么Order.Submit().这是你的BLL,它所关心的只是业务逻辑.应该没有UI问题,没有数据持久性问题,没有任何类似问题.这是定义业务逻辑的核心程序集,可以在域中的任何应用程序中重用.
2. 定义数据持久性.这是您的业务模型与数据库相遇的地方.它可以是一个数据库,多个数据库,数据库/文件系统/服务等的混合,等等.(现在,真正的持久性无知是域驱动设计的圣杯.你的模型可能必须为你的基础设施做出一些妥协.它会发生.)
3. 定义您的应用程序 这些可以是用户界面,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容器时要使用哪些接口.

这种方法使关注点非常清晰.您可以根据需要使用域核心拥有尽可能多的应用程序,并且可以根据需要拥有尽可能多的依赖项实现(包括测试模拟实现).

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