DMVP 190525-0530 知识星球问答总结
本周知识星球又来新人啦，为了节省时间，我把本周的问题整理一下，方便后面进星球的同学观看学习。
本周主要以公寓租房(自如租房)的形式，发布了三篇文章，主要集中阐述了如何快速的从产品需求文章中获得通用语言。我们40篇文章都是围绕公寓租房这个案例进行，从 0 到 1 搭建系统，就为了和星球小伙伴一起实操。
历史文章目录（部分文章免费，部分收费）：http://wenhe.online/?p=2043
业务框架 DMVP 介绍，这不仅仅是技术脚手架，这是根据业务的领域模型生成的业务框架，生成的代码和你画的业务是对应的，并且维护了模块，package，类名，领域对象之间的联动关系。介绍地址：http://wenhe.online/?p=1881
广告打完，开始正文
本周问答：
问：旧系统不内聚，很难解藕，如何用 DDD 重构或改善？
答：个人理解旧系统分为两种，一种完全是个大杂烩，上日常需求都会发生故障的系统，这种是无法改善的，建议用 DDD 重构。另外一种是系统比较稳定，有一定的业务概念，但不是很内聚，这种是完全可以重构的。
重构的思路：理清领域模型，逐步切流迭代。
我们用租房的例子来演示过程，假设你现在租房主要分成三步：房源合法性校验、签订租房合同、发出合同消息。
我们用 SpringMVC 进行实现老系统(好几年没用 SpringMVC 了，搞了好久，不知道写出来的对不对，不对的话欢迎交流)：
首先模块+package分层：
圈里面有用 SpringMVC 做业务的同学帮忙看看，的确是这样子的吧，我毕业第一年使用过 SpringMVC 做过业务项目，后面都在用 DDD ,有点记不清了，有误之处还请多多指正，谢谢。
具体的逻辑如下：
如果我一直用 SpringMVC 做项目，不知道 DDD 的话，或者我没有去经历过一些复杂业务场景的话，我可能认为业务架构这么写，是没有问题的，但熟悉 DDD 之后，你再回来看这样的代码，你会发现 MVC 根本做不到高内聚低耦合，甚至时刻都能成为大杂烩的风险，我们随便列举几点：
1:业务不够内聚
2:代码架构做不到低耦合
其实还有很多问题，比如说分层问题，领域能力的完整性问题，领域能力的归属问题等等，篇幅有限，我们就不一一介绍了，星球伙伴们可以自行前往git下载代码寻找这些问题，然后在星球讨论，或者直接找我讨论。（这里我们尽量从业务架构的层面去找，不是简洁代码层面哈）
接着我们用 DDD 进行演示一下：
首先我们把租房的业务场景抽象成通用语言，再进行建模，至于怎么抽象成通用语言，我们在知识星球刚刚连载三篇文章，我们就不细说了，我们在DMVP 页面进行建模，流程如下：
首先我建立了两个实体，一个叫做房源实体，一个叫租房合同实体，并且新增了属性和领域能力，如下图：
接着为租房这个动作生成了一个领域服务，如下图：
最后我们新建一个应用服务，就是一个流程，把我们刚才新建的领域服务和能力进行编排：
好了，针对租房场景，领域模型建模完成，我们接着点击生成代码，我们下面贴图会把 DDD 格式的代码和 MVC 格式的代码做一个对比，左边是 DDD 格式的。
DDD 分层(开发无需关心分层)：
app 层：
领域服务，对租房合同的领域能力进行编排，MVC 没有领域服务的概念， MVC 代码就不展示了：
领域对象，租房合同实体：
基础设施层，spi层，wen层其他层生成的代码，就不细说了，这里就给大家演示了一下如果让我来落地租房场景的DDD实战过程，是不是还蛮快的？
我们用 SpringMVC 实现了旧系统，用 DDD 演示了我们要达成的样子，现在如何在旧系统上面改造呢？
我们不说业务上如何改造，因为业务如何改在是你在改造前必须想好的，针对不同场景的战略设计都不同，当然也是有一些参考方法论的，但对你不一定适合，具体的可以关注星球，所以我们仅仅从代码层面mock一下，看看是否可以给你带来一些启发。
我们分成两种目标，第一种就是原来的代码完全不行，我想另外搞一套，另外一种是原来的系统还可以，只是部分需要用 DDD 替换，我们先说第一种
我们经验分2步：
A1：老功能不动，新功能用 DDD 方式实现，达到新需求可接可跑。
A2：老功能代码用 DDD 重写，线上领域能力执行结果对比，稳定切流。
为了达到A1 步骤如下：
1：建立新的 DDD 系统，按照刚才演示的方式进行快速搭建。(当然如果你考虑成本的话，可以直接把 DDD 代码拷贝到旧系统上，这样减少了新系统机器的部署 )
2：老系统上进行一定业务规则的分流，因为流量的入口还是老系统，这个改变不了，我们只能在老系统入口出进行逻辑分流，实现如下：
为了达到 A2，思想如下：
我们需要在 DDD 系统中重写老系统的功能，对于写的流量，我们可以根据白名单，百分比进行切流，对于查询的流量，我们可以把新老查询都执行一遍，最后检查新老查询的结果是否一致(写个执行控制器和结果对比器就好了，也很简单，就不上代码了)。
以上是针对全量切换到 DDD 系统的思想演示，接着我们来说第二种：原来的系统还可以，只是部分需要用 DDD 替换。
我们思路只有一个：在要做的事情内部进行切流！我们要做的事情可能是领域能力和领域服务。
假设刚才租房流程中，对于房屋的合法性校验，本应该是房屋实体应该做的事情，但 MVC 的实现里面却是个 service，我们现在用 DDD 替换掉这个service，步骤如下：
1：首先我们需要在 service 内部进行分流，新流量打到 DDD 实现上，这里有个注意点就是为什么是在 service 内部进行分流，而不是 service 的上层？我们用代码演示下：
推荐直接在service里面做分流：
不推荐在service外面做分流：
2:当分流稳定后(可能需要几个月的时候)，直接在controller层进行替换，如下图：
最后一点建议，旧系统用 DDD 进行改造是需要成本的，一个复杂的系统，可能需要几年的时间，所以要做好长久战的准备，比如可以通过文档记录什么时候改了什么功能点，什么时候开始切流，切流过程中遇到什么问题，什么时候切流结束等等。
当然为了拿到绩效，可以先让新业务在 DDD 系统上先跑起来。
本周星球成员沟通的问题其实很多，这个问答不知不觉写了这么多，剩余的问答下周再发出来吧，当然你也可以直接加入星球讨论，加入星球你可获得：
1：40 课章节内容，以公寓租房(自如租房)为案例，从 0 到 1 一起实操。
2：DMVP 业务框架帮你提高落地效率，7，8月份会推出流程引擎，让你的业务跑的更迅速。
扫码即可关注：
DDD 落地群，入群会获得 DDD 资料，可以向我提问，好的提问会有图文解说，下班后都会回答，失效了可以加我微信：luanqiu0
也可以关注我的微信公众号，我就不发二维码了，打广告的嫌疑太重了，我已经羞愧到无地自容了，maybe this is life。