一、编排业务逻辑的模式
1. 事务脚本模式TS（The Transaction Script pattern ）
- TS模式概述
TS 鼓励你跳过任何的面向对象的设计，你直接到所需的用户操作的业务组件映射。专注于的业务用户可以通过表示层完成，并为每个请求编写方法。这个方法被称之为事务脚本，此处事务通常是指想要进行商业交易，脚本是指系统中的一系列关系用户操作的系统操作。
TS历时多年仍然不过时的原因只有一个：它基于推行可视化的业务逻辑设计，而可视化正上用户体验的核心。
在TS中，每个用户操作都在上下文的物理事务边界中完成。不同于数据访问层的数据执行脚本，TS的数据访问通常被封装在数据个组件中。按照设计，TS不包含使用面向对象设计。TS中的任务逻辑都是If,while,for等组成。
- TS模式实际应用
在实现中每个TS都是一个单独的，可能表现为一个类的静态方法，可以在每个类自己执行TS。当你这样做的时候，就已经完美演绎了命令模式。
命令模式的主要设计思想是用一个对象来表示动作。命令对象封装一个动作和它所有的参数。典型的，命令对象公开的标准接口，以便调用方可以调用任何命令，而无需关注命令类的具体行为。如：
public interface IApplicationCommand
{
int Run();
}
public class BookHotelRoom : IApplicationCommand
{
Customer _guest;
DateTime _checkIn, _checkOut;
String _confirmationNumber;
// other internal members
public BookHotelRoom(Customer guest, DateTime checkIn, DateTime checkOut)
{
_guest = guest;
_checkIn = checkIn;
_checkOut = checkOut;
}
public String ConfirmationNumber
{
get { return _confirmationNumber; }
}
public int Run()
{
// Start the transaction
// Check room availability for requested stay
// Check customer information?(already guest, payment method, preferences)
// Calculate room rate
// Add a new record to the Bookings database table
// Generate the confirmation number
// Commit the transaction???????
// E-mail the customer
// Store the confirmation number to the local member _confirmationNumber
}
...
}
TS模式不对任务数据设计权限，不也会对数据做任何转换。它只用用于接收和发送数据，所以通常的做法是使用数据类（Dto）来传递数据。
2. 域模型模式（The Domain Model pattern）
域模型（DM）通常在DDD设计中使用，但也不局限于它。DM也是一个常用的设计模式，它让架构师侧重于系统的预期行为和运行时的数据流。
- DM模式概述
域模型是不同于对象模型的一系列集合。域模型忠实于表示业务领域，特别是域内进程的数据流。
- DM模式实际应用
域模型是一系列表示业务领域的plain old classes。这些类是数据容器，可以表现为属性也可以是方法。The term POCO (Plain Old CLR Object)通常指这些域模型。
实际使用我们不关注类本身，关注的是行为和事件。这些行为能帮助你理解在类上发生了什么。着眼于行为比着眼于类属性更有用，另一方面看来，这就是Tell-Don't-Ask原则的体现。
有些时候域模型需要被持久化，而持久化不是域模型的职责，持久化将在基础结构层才能被实现。从应用程序看来域模型是业务逻辑数据库，不依赖任何接口，而持久化依赖接口，使用关系模型来持久化。域模型和关系模型通常要通过ORM工具来完成，如Microsoft's Entity Framework 和 NHibernate
3.反域模式ADM（The Anemic Domain Model (anti-)pattern）
域模式的核心于对象关联的行为，"行为先行"是违背域模型设计原则的，所以产生了另外一种模式，反域模式（ADM）。
- ADM概述
ADM域模型中，所有对象仍然都遵循命名约定的真实世界域实体、 实体之间的关系仍存在，和模型的整体结构紧密匹配的真实域空间。没有行为，只有属性的实体。
ADM模式建议不要在域对象里放任何逻辑。所有的逻辑都被放在逻辑领域的服务组件里。这此服务是域模型的消费者，并且有存储和持久化的功能。
■ Analysis leads to objects that closely model the domain space and are tailored to the real
needs
■ The strong domain perspective of things reduces the risk of misunderstandings between the
domain experts and the development team
■ Code is likely to become more readable and easily understandable
■ The fnal result has more chances to really be close to expectations.
二、将关注点从数据转移到任务
1. Asp.net Mvc中的任务
用户行为最终被实现为controller类中的一个方法调用。controller应该是被用来组织任务的首选。抽象的说，Contrller与WebForm中的postback事件没有区别。在这两个方法中，聪明的开发人员都会为了避免web form中的完整的事件执行而选择使用Controller。
- Controller是一个协调者
Responsibility-Driven Design (RDD)职责驱动设计由Rebecca Wirfs-Brock 和Alan McKean提出：Roles, Responsibilities, and Collaborations。RDD的本质是将系统分解成一系统可执行的Action动作，然后每个action被映射到一个组件类。执行action被设计成组件类的职责。组件的解决依赖于它设定的职责。
Asp.net mvc 的controller是RDD模式的一个生动的实现，RDD协调者建议将action分组到一系统application services中，由controller 调用services来执行action返回view model
public ActionResult PlaceOrder(OrderInputModel orderInfo)
{
// Input data already mapped thanks to the model binding
// infrastructure of ASP.NET MVC
// Perform the task invoking a application service and
// get a view model back from application layer
var service = new OrderService();
var model = service.PlaceOrder();
// Invoke next view
return View(model);
}
controller负责展现层和应用层的协调调用，这种情况下如果需要不同的展现层，可以用以下代码轻松实现：
var service = new OrderService();
var model = service.PlaceOrder();
// Adapt to the new view model
var newFrontendModel = someAdapter.NewViewModel(response);
- 连接应用层和展现层 Connecting the application and presentation layers
应用层和展现层的连接点是controller,使用依赖倒置模式Ioc容器如microsoft unity来重写asp.net mvc的controller factory:
var factory = new UnityControllerFactory();
ControllerBuilder.Current.SetControllerFactory(factory);
UnityControllerFactory实现如下：
public class UnityControllerFactory : DefaultControllerFactory
{
public static IUnityContainer Container { get; private set; }
public UnityControllerFactory()
{
Container = new UnityContainer(); // Initialize the IoC
Container.LoadConfiguration(); // Configure it reading details from web.config
}
protected override IController GetControllerInstance(RequestContext context, Type type)
{
if (type == null) return null;
return Container.Resolve(type) as IController;
}
}
然后每个controller类的默认构造函数要改成如下：
public class HomeController
{
private IHomeService _service;
public HomeController(IHomeService service)
{
_service = service;
}
...
}
You can use the Unity Mvc library available as a NuGet package For more information, see http://github com/feedbackhound/Unity Mvc5
- 连接应用层和数据访问层 Connecting the application and data-access layers
同样的问题存在于数应用层和基础架构层的数据访问。使用相同的方法——依赖注入。在域模型场景中的数据访问逻辑容器通常被命名为repository
public class HomeService
{
private ISomeEntityRepository _someEntityRepo;
public HomeService(ISomeEntityRepository repo)
{
_someEntityRepo = repo;
}
...
}
有意思的是，你不需要在代码中修改初始化controller来设置factory，你只要确保仓储类型和接口都映射到Ioc容器里就可以。所有Ioc容器都提供配置和api两方式来映射类型。所以不需要再通过代码来配置，现在的IoC容器都提供了这种透明的方式来解决依赖关系。如果你通知IoC容器获取一个Controller类型，这个controller类型依赖一些Application Services类型，反过来，Services类型又依赖一个或多个仓储类型，所有这些代码都在一行代码里解决。
层与层之间的连接通信建议使用依赖注入实现，但它不是唯一的解决方案。如果你有多个层在同一个进程空间内，比较简单的方法是直接并且本地实例化对象，不论他们在application layers、servces layers或是respositories layers. 缺点就是他们会在层之间产生高偶合。
// Tight coupling between the class OrderService
// and the class that contains this code
var service = new OrderService();
var model = service.PlaceOrder();
2. 编排域内的任务
通常、应用程序的逻辑层包含了任务编排、域逻辑和一些其它的东西。
- 跨实体域逻辑
域名服务通常包含业多个域实体操作的业务逻辑。大多情况下，域名服务是复杂、 多步的操作，都在域的边界内进行，并有可能是基础设施层（infrastructure）。典型的例子是OrderProcessor, BestPriceFinder, 或GoldCustomerEvaluator这样的域服务。服务的命名以功能命名，并且可以让领域专家和相关人员容易理解。
三、跨边界传递数据
表示层物理边界跨界，无论是进程跨界还是物理计算机跨界都是一项很昂贵的操作。访问一个远程计算机的效率可能要比进程内通信慢100倍。
1.层架构间的数据流
下图表示分层架构一个抽象的数据流。当执行一个命令执行时，数据流从用户接口以一个input model形势进入应用层。鉴于这个请求动作，应用程序层需要一系列用来做为input model的域模型实例。在一个领域分层系统中，持久性特指将转换成物理模型，妈实体关系模型（relational-data model）,在返回结果时将data mode再转换为demain model。
理论上讲，一个分层的系统由上图的4种逻辑分离的model组成，但在有的情况下他们是一致的。data model通常与demain model在基础设施层是一致的。在Asp.net mvc应用程序中，input model与output model通常是同一个model。
- 共享域模型实体（Sharing the Domain Model entities）
在遵循域模型配置设计的架构中，域实体与数据紧密相关，推荐将域模型向表示层冒泡，并且在必要的时候将他们序列化来传输。
- 使用数据传输对象
在一个解决方案中很少能让一个实满足整个系统的需要，毕竟不同的层可能对数据要求不一样。有些情况下，为了便捷使在所有层中都使用了demain model，有些情况下需要使用Dto类，总之、跟据你的需要。
- Dto对象概述（data-transfer object）
Dto被设计为用来做物理层之间的数据载体。Dto类只有属性，没有行为。Dto原生可以被序列化，在远程组件调用中通常这样做。
- DTOs 与. domain entities区别
典型的DTO使用如：显示和处理一个自定义订单。在处理订单时需要大量的数据，显示数据时只需要简单少量数据。DTO增加了层次的复杂度，但是减少了容器的复杂度。
- AutoMapper 和适配器
Data model 与DTO之是可以通过AutoMapper适配器完成自动转换。
Mapper.CreateMap<YourSourceType, YourDtoType>();
Once a mapping is defned, you invoke it via the Map method:
var dto = Mapper.Map<YourDtoType>(sourceObject);