业务层——把焦点从数据移到任务

把焦点从数据移到任务

这幅图展示了产出模型的忠实程度与被观察的流程之间的关系。毫无疑问，领域驱动设计改善了忠实程度。DDD的出现也开启了从以数据为中心的设计向基于任务的设计转变的过程。这种自然而然的转变本质上受到在某种程度上处理复杂性的需要的驱使。

向基于任务的世界前进是“说，别问”原则的终极启示.。任务是每个用例以及用户和系统之间的每个交互背后的工作流。从设计的角度来看，包含介于表现和数据之间的一切的这一层是一个相对臃肿的层。就这点而言，把任务编排隔离到一个单独的层可以还领域逻辑代码一片净土。领域逻辑更适合放入领域对象，如果使用贫血设计的话，就放入单独的模块。

ASP .NET MVC里的任务编排

在ASP .NET MVC应用程序里，任何用户界面操作最终都会转化成控制器的类上调用的方法。应避免把所有编排逻辑放入Button1_Click事件处理器，同样地，也应该避免把所有编排逻辑放入控制器方法。

把控制器看作协调者

责任驱动设计（Responsibility-Driven Design，RDD）。
RDD的本质是把系统特性分解成系统必须执行的多个操作。接着，每个操作对应正在设计中的一个组件（通常是一个类）。执行这个操作就变成这个组件的专门责任了。这个组件的角色取决于它所承担的责任。

RDD定义了一套原型（stereotype），用来分类每个组件的角色。其中一个RDD原型（协调者）非常贴切地描述了ASP.NETWC控制器的理想原型。RDD的协调者原型建议你把构成操作实现的所有步骤组合起来放入单个应用程序服务。然后，从控制器方法里调用应用程序服务，并把它的输出传给视图模型对象。如下：

public ActionResult PlaceOrder(OrderInputModel orderInfo)
{
    // OrderInputModel - 订单输入数据已映射到OrderInputModel中
    // 执行任务调用应用程序服务，从应用程序层获取视图模型
    // 对Orderservice类的调用正是穿越表现层和应用程序层之间的边界的例子
    var service = new OrderService();
    var model = service.PlaceOrder();
	// 适配新的视图模型
	var newFrontendModel = someAdapter.NewViewModeI(response);
    // 调用下一个视图
    return View(model);
}

连接应用程序层与表现层——MVC自带

应用程序层和表现层之间的交接点是控制器。使用Microsoft Unity实现控制反转(IOC)模式。
在global.asax里，在应用程序启动时注册一个自定义的控制器工厂：

var factory = new UnityControllerFactory();
ControllerBui1der.Current.SetControllerFactory(factory);

UnityControllerFactory类

public class UnityControllerFactory : DefaultControllerFactory
{
    public static IUnityContainer Container {get; private set;}
    public UnityControllerFactory ()
    {
        Container = new UnityContainer(); // 初始化loc
        Container.LoadConfiguration();    // 从web.config加载详细配置信息
    }
    protected override IController GetControllerInstance(RequestContext context,Type type)
    {
        if(type = null)
            return null;
        return Container.Resolve(type) as IController;
    }
}

调用

public class HomeController
{
    private IHomeService _service;
    public HomeController(IHomeService service)
    {
        _service = servIce;
    }
}

连接应用程序层与数据访问层

通过依赖注入连接应用程序层与包含数据访问代码的基础设施层。

public class HomeService
{
    private ISomeEntityRepository _someEntityRepo;
    public HomeService(ISomeEntityRepository repo)
    {
        someEntityRepo = rePO；
    }
}

在领域里编排任务

一般而言，应用程序的业务逻辑包含任务编排、领域逻辑以及一些附加的东西。这些附加的东西通常是指领域服务。简而言之，领域服务包含任何无法放入领域实体的逻辑。当遵循领域模型模式的指导原则时，业务逻辑大多数情况下会分散到不同的领域实体。如果某些概念无法以这种方式处理，那么它们就属于领域服务的范畴了。

跨实体的领域逻辑

领域服务通常包含的业务逻辑的操作牵涉多个领域实体。大多数情况下，领域服务是复杂的多步骤操作，它们在领域甚至基础设施层的边界里执行。
领域服务的标准例子是OrderProcessor、BestPriceFinder或GoldCustomerEvaluator等服务。（需遵循统一语言，取名应反映现实操作，并且容易被利益相关者和领域专家理解。）
例如，GoldCustomerEvaluator，在一个电子商务系统里，在用户下订单后，可能需要判断这个新的订单有没有改变这个客户的状态，因为它可能己经超过指定的最低销量。为了执行这个任务，需要读取这个客户的当前销量，在上面应用某些奖励系统的逻辑，然后判断新的状态。在一个真实的实现里，这可能需要你读取Orders表，一些与奖励有关的视图，以及执行某些计算。最终，它混合了持久化、订单、客户和业务规则。涉及的实体不止一个，而逻辑也是跨实体的。于是，它的最佳容身之所是领域服务。
最后，定义成领域服务的操作大多数情况下都是无状态的：传入某些数据，然后获得某些结果。没有状态维护，可能除了某些缓存。

连接字符串在哪？

领域模型里的实体应该是普通C#对象（Plain-old C# Objects，POCO），并且与持久化无关。换句话说，Invoice类只包含日期、编号、客户、项目、税务信息以及支付条款等数据。此外，它可能包含GetEstimatedDateOfPayment方法，这个方法读取日期和支付条款，计算一下节假日，然后确定发货单的支付日期。

从存储读取Invoice实体的代码和把它保存到存储的代码并没有和实体本身放在一起。系统的其他组件会处理这点。这些类就是仓储。它们大多数情况下涉及CRUD功能以及你可能需要的任何附加的持久化逻辑。仓储是整个系统里唯一处理连接字符串的地方。

你应该关心物理层吗？
多个物理层通常并非一个系统里该有的好特性。MartinFowler曾经说过，分布式编程的第一军规是：“不要使用分布式对象，至少要到完全必要时才使用。"物理层降低整体性能，提高整体复杂性。这两点都影响了构建和维护应用程序的整体成本。即便如此，某些物理层也是无法避免的。因此，它们在一定程度上是恶，但也是必要的恶。
举个例子，在用户的机器上运行的代码和服务器端代码之间就存在不可避免的障碍。服务器端代码和数据库服务器之间则存在另一个典型的分隔。Web应用程序多数属于这类。
此外，每个应用程序都有自己的好理由引入多个物理层。一个理由可能是要支持的外部产品需要自己的进程。多个物理层的另一个好理由是对安全性的追求。一个模块运行在隔离的进程里更易受到保护，仅限授权调用方访问。
少数情况下，多个物理层可以用来提高系统的可伸缩性。更准确地说，把系统的某些可以远程访问的组件复制到额外的物理层比起没有这样做可以获得更好的可伸缩性。但可伸缩性只是系统的一个方面。通常，对可伸缩性的追求一一也就是在一定压力下保持性能稳定的需要一一损害了日常性能。
总之，物理层的数量原则上应该尽可能少。添加新的物理层应该在谨慎分析成本与收益之后才能进行，其中，成本通常牵涉增加复杂性，而收益则牵涉安全、可伸缩性以及容错等方面。当然，你看到过系统集成人员创建疯狂的三层或者更多的系统（尤其是2000年初），然后很疑惑为什么系统采用了正确的架构方案还是那么慢。