封面前言
随着微服务的兴起，领域驱动设计（DDD）架构逐渐受到了更多人的关注。然而，在实践方面，人们对DDD的理解和运用仍存在很大的差异。今天，我们将对DDD进行一个浅浅的理解和尝试。
本文不含复杂的概念，只是个人理解。
历史
早在2003年，第一本关于DDD的书籍《领域驱动设计：软件核心复杂性应对之道》问世。由此算是正式提出这个概念。但是只有小部分科技圈的人才有讨论的声音。
到了2013年，又一部巨作《实现领域驱动设计》诞生，在本书中的一些概念，比如领域事件，六边形架构，战略设计，沿用至今。
同年，出现了时间风暴建模法。
在国内，随着微服务的兴起，DDD便逐渐开始流行。
领域驱动设计实战
软件的诞生，就是为了逐步取代人工，从无纸化到AI加持的数字化。业务的复杂，也带来了技术的复杂。
在传统架构模式中，各个模型之间没有单独的空间，一层经常包含几十个不同业务的类。而且，随着业务、场景的增加。原本的对象变更次数更多。所以这次实战，选择最常见的电商，智能售卖机。
前置知识
单App架构看整体知局部，从图可以看出，最重要的就是左下角蓝虚线框中的部分。这看起来和MVC结构相似，不同的是，这里有N个这样的结构。代码层面来看：
代码语言：yaml复制交易： dao、vo、repository
用户： dao、vo、repository
支付：dao、vo、repository
...表面看起来好像只是创建包结构，分出更多层，但实际上，对象已经被拆分开来。共通的属性，要跳出domain层。这一步是为了防止“污染”。每个domain之间不是相互隔离的，总是有一定边界上下文，与领域划分。
模型与事件
从立项出发，我们需要收集真实的用户。与用户对话，听用户故事。那么得到类似如下
- 扫码支付
- 免密付款
- 售卖机投放
- 补货
- 。。。 每一项都是真实世界的东西，要用软件建立对应的模型。那么再根据整个流程区分出不同的事件。所有的一切需要小组一起讨论，确定统一的设计语言。
领域划分和限界上下文
SmartRM从从交易域、支付域、商品域等交叉出交易上下文，支付上下文等边界。
以核心的交易为例子。
在设备X交易的场景中，交易对象和设备对象需要增加一层关联关系，按照传统MVC，直接追加属性。但是因为不止一种交易，在交易X商品中又需要增加属性。而DDD将这些混合的属性剥离开，单独放在一个防污层里，不破坏原有对象。
生动点说，一条裤子大家穿，有人想加裤带，有人想加裤兜，最后这条裤子面目全非。而DDD就是你想加属性，好，咱们复制出一个裤子，再追加挂件，回归代码，就是用组合替代继承。
防污
第一次看到这个词，会感觉很奇怪，其实我们常用的DTO就是这样的功能。在实际使用的数据和领域对象加一个中间层，不仅可以防止内部不正常的操作影响真实数据，还可以用于与外部系统的对接中。
总结
今天探讨的内容中，多次提到MVC。因为如果在小型系统中，从MVC过度到DDD是件很容易的事。不过，切记，DDD是一种思想，落地需要统一团队的设计语言。还有，不要知道了DDD就变成榔头，看谁都像钉子。
