今週は時間を節約するために、私は戻って惑星の学習に学生を見やすい、整頓、今週の質問を入れて、新しい知識惑星状物質を来ました。
今週は、主にマンションの家賃の形で主に迅速記事からの製品需要の共通語を取得する方法に焦点を当て、3件の記事を公開し、（自由に借ります）。私たちの記事がこのケースを約40アパート借りたされ、一緒に0-1から、ほんの少しのパートナーの惑星と実用的な操作にシステムを設定します。
歴史記事のディレクトリ（記事の自由な部分、手数料の一部）：http://wenhe.online/?p=2043
ビジネスフレームワークDMVPは、ドメインモデルのビジネス・サービス・フレームワークに基づいて生成されるだけでなく、技術的な足場を導入し、生成されたコードは、あなたは、オブジェクト間の対応するサービス、およびモジュールのメンテナンス、パッケージ、クラス名、フィールドを描きますリンケージ関係。住所：http://wenhe.online/?p=1881
広告キックは体を開始します
今週のQ＆A：
Q：古いシステムは、分離することは困難である、粘着性ではない、DDDはどのように再構築または向上させるには？
：私は個人的にこれを向上させることができない、システム障害の日常のニーズが発生し、1は完全に寄せ集めで、古いシステムは二つのタイプに分けて理解し、DDDと提案した再建。別のシステムは、操作の特定の概念安定しているが、非常に粘着性ではない、これは完全に再構築されています。
アイデアを改造：ドメインモデルを整理し、徐々に流れの反復をカットします。
私たちは、あなたが3つの段階に分けて借りていると仮定すると、借りるのプロセスを説明するために例を使用します。リスト合法性チェック、賃貸契約を締結し、契約書には、メッセージを発行しました。
我々は（数年前から無用SpringMVC、と長い時間に従事、私は、共有してください、間違った、間違っを書き出すために知っていない）SpringMVCと古いシステムを実現します：
まずモジュール+パッケージ成層：
便利なSpringMVCそれは本当にしてください、私はDDDと背面の両方で、使用SpringMVC行わビジネスのプロジェクトを卒業し、このように最初の年であるビット覚えていない、また間違っている、見て助けるために、学生の円の内側にビジネスを行います私を修正、ありがとうございました。
次のように具体的なロジックは次のとおりです。
如果我一直用 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。