.NET：关于数据模型、领域模型和视图模型的一些思考

背景

数据模型、领域模型和视图模型是“模型”的三种角色，一些架构用一种类型表示这三种角色，如：传统三层架构。也有一些架构用两种类型表示这三种角色，如：结合ORM的领域驱动架构。非常少见的场景是用三种类型表示这三种角色，我只在个别领域这么弄过，如：工作流引擎。

今天只说一个话题：是否有必要为视图模型引入独立的类型？还是用一种类型表达领域模型和视图模型这两种角色比较方便？引入一些词汇：

• A方案：用一种类型表达领域模型和视图模型这两种角色，又叫公开领域模型到视图（Open Domain To View）。
• B方案：为视图模型引入独立的类型，又叫使用数据传输对象（DTO）。

A方案

因为领域模型和视图模型是一个类型，所以领域模型会从UI进行重建，因为领域模型会从UI进行重建，而UI层是不能相信的，所以必须对领域模型进行验证（包含IsValid()方法），而且领域的很多方法都是修复领域模型的非法状态，如：重新计算订单总额、加密未加密的密码属性等等。

代码示例

 1     internal sealed class TestGridCommandHandler : ApplicationService,
 2         ICommandHandler<CreateTestGrid>,
 3         ICommandHandler<UpdateTestGrid>,
 4         ICommandHandler<DeleteTestGrid>
 5     {
 6         public void Handle(CreateTestGrid command)
 7         {
 8             var testGridService = this.Service<TestGridService>();
 9 
10             testGridService.Create(command.TestGridInfo);
11             command.Id = command.TestGridInfo.Id;
12         }
13 
14         public void Handle(UpdateTestGrid command)
15         {
16             var testGridService = this.Service<TestGridService>();
17 
18             testGridService.Update(command.TestGridInfo);
19         }
20 
21         public void Handle(DeleteTestGrid command)
22         {
23             this.Service<TestGridService>().Delete(command.Id);
24         }
25     }

注意看第二个方法，这里的command.TestGridInfo就是领域模型，从客户端重建后直接调用ApplicationService进行update，update负责修复模型状态、执行验证和处理乐观并发。

B方案

因为领域模型和视图模型是一个不同的类型，所以领域模型不会从UI进行重建，因为UI进行重建的只是视图模型， 所以要从数据库加载一份领域模型，然后将视图模型合并到领域模型中，这里的合并不是指用AutoMapper这样的合并工具，而是一种合理的合并过程（不能用反射绕过领域模型封装的逻辑），在这个合并过程，领域模型始终处于合法状态（也可以不合法，很多人都这么弄，保留IsValid()方法即可）。

代码示例

 1     internal sealed class TestOrderCommandHandler : ApplicationService,
 2         ICommandHandler<CreateTestOrder>,
 3         ICommandHandler<UpdateTestOrder>,
 4         ICommandHandler<DeleteTestOrder>
 5     {
 6         public void Handle(CreateTestOrder command)
 7         {
 8             var testOrderService = this.Service<TestOrderService>();
 9 
10             var testOrder = command.CreateTestOrder();
11 
12             testOrderService.Create(testOrder);
13             command.Id = testOrder.Id;
14         }
15 
16         public void Handle(UpdateTestOrder command)
17         {
18             var testOrderService = this.Service<TestOrderService>();
19 
20             var testOrder = testOrderService.Repository.Load(command.Id);
21             testOrder.CheckOptimisticKey(command.TestOrderInfo.OptimisticKey);
22             
23             command.UpdateTestOrder(testOrder);
24             testOrderService.Update(testOrder);
25         }
26 
27         public void Handle(DeleteTestOrder command)
28         {
29             this.Service<TestOrderService>().Delete(command.Id);
30         }
31     }

注意看第二个方法，这里先用Repository从数据库返回一个领域模型，执行乐观锁检查，用视图模型修改领域模型（不是简单的反射），然后调用ApplicationService进行Update。

备注

只看代码大家可能觉得A方案比较简单，而B方案视乎有点脱裤子放屁的感觉，我之前都是用的A方案，开发效率确实高，但是应对比较复杂的逻辑就非常不爽了，具体为啥不爽我还没有想明白。

我现在非常有信心用好任何一个方案，因为一个高人告诉我：关注代码细节胜于关注这些架构上的问题。

结合四色原型，我觉得可以这样弄：PPT和DES用A方案，MI用B方案。