一、背景
在业务开发过程中存在这样一种情况，比如草稿箱，类似于合同或者变更草稿，中间存在一些审批流程，审批完成之后将数据从草稿箱或者草稿表中移动到正式表中。可能其中的区别就在于一些状态审核字段，关于这个场景在常规操作下和DDD下是怎么样的，本文将深入探讨这个话题。
二、业务场景
以下几个场景都是我曾经遇到过的，这里简单介绍下业务流程
2.1 电子合同的创建与发布
电子合同有个合同模板，通过模板+业务设置的合同变量Key生成一份草稿合同模板，草稿合同模板会通过法务审批形成正式的合同模板，状态已上线，签署之后就作为正式合同存在，同时带有版本号，同一份模板的合同只有一个是生效的合同模板，另外通过版本号来标示历史合同的变更情况，关于变更的合同记录会放到历史表里面。整个技术和业务实现就是说会创建四个合同模块，草稿合同模板，正式合同模板，历史合同模板，正式合同。在模板领域里则有对应的6张表，结构基本一样(合同模板+合同变量表各一张)。从常规的业务流上看就是草稿到正式再到历史。表结构几乎一样。那么从DDD的角度看是否可以做一些精简呢？个人认为是可以的：
-
模型精简
在模块上可以基于领域模型构建通用的合同模板，合同变量对象，基于子类做个性化属性实现。底层的话是否做抽象+继承这里个人觉得不需要动，单表对单对象即可。基于DDD的视角下其模型如下UML类图：
2. 工程精简
在工程精简方面上主要体现出领域服务接口的定义和模块的聚合，在这里整个合同模板是聚合根，合同变量配置相对独立，但是合同上的变量列表是与之关联的，所以在分包定义上可以定义一个合同模板包，至于正式的合同则可以单独成为一个聚合根，那么在模块上面就不会存在多个功能相似的了。
-
底层表结构是否需要精简
这里底层的表结构是否需要精简需要看业务，大部分场景下不管什么方式不精简应该是比较合适的选择，因为数据量在单表存在冗余，同时数据量大的情况下会出现性能问题，同时引发一些维护迭代问题。
2.2 变更审核机制
在营销系统中，需要对已有的系统做升级优化，针对用户的每个操作都需要保留一份草稿数据，走审批流，审批流完成之后才可以将数据推到正式表里，对用户才可见。
2.3 员工视图
之前做过的hr系统中，针对不同状态的员工信息均有单独的分页列表视图，但是大部分属性基本相同，此时在模型上则更多的像是一种读视图，在部分员工管理页上也存在员工数据导入等场景，那么在领域模型上和业务接口模型上则更多的像是一种模板与实例的关系。如果采用常规的做法来看实现方式可能会更加冗余。
三、模版实例模式
3.1 模板实例模式的定义
基于给定业务模型复制出或者继承得到的实例对象，与其模板可以自成一体，形成单独的模块或者聚合对象。
3.2 必要性
很多时候针对领域模型的不同操作状态，不同业务视图或者视角下对其单独建模，但是产生了冗余，模块之间的联动并不多，更多的像是一种模型的复制,业务能力在接口上体现的比较弱，所以基于DDD视角下构建一个模板实例模式来表示这种场景，去探索一种更好的解决方案。
3.3 设计模式
这个模式看上去更像是一种设计模式，比如工厂模式,模板方法模式，或者策略模式，但是实际上关于模型的模式可能这个描述更好一些，实际上要实现这个模型的模式还需要设计模式中的原型模式或者工厂模式，或者模板方法模式。
3.4 适用场景
-
草稿箱 -
读视图 -
全量变更记录(日志)
原文始发于微信公众号（神帅的架构实战）：DDD落地的思考–模板实例模式
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/241387.html
