DDD领域建模与系统实战

基于上下文的业务流建模法的文章系列已经到了第四篇了，本篇也是最后一篇，来讲一下关于这个建模方法的一些缺点以及如何优化它，基于这个建模方法我们如何更好更快的构建业务模型。

一、背景 前面两篇文章已经给大家展示了一个相对新颖的建模方法，也简单实战了下，这里我通过一个生活中的例子来模拟快递业务中的模型构建过程，本篇将完整的展示一下基于上下文的业务流建模法的操作过程。 事情的

一、背景 上一篇文章说到了我提出了一种新的建模方法，并对建模方法的大概内容做了阐述，本次我将继续对这个建模方法做进一步的说明,并提供一个小小的案例来熟悉一下建模套路。下一篇文章将通过其他案例来展示这种

一、背景 DDD相关的建模方法就目前看已经在实践的建模方法已有6种之多，之前的技术分享中也有大佬尝试通过一些新的方法或者理论来帮助统一DDD建模，这其中的原因也是因为希望找到一个比较好的或者适用性更广

最近有微信朋友在公司内部分享的时候有人问领域划分的规则是什么？意思就是你怎么知道一个领域需要划分哪些子领域？有没有依据，是凭直觉吗？本文将重点讨论下这个比较现实的问题。

一、背景 在学DDD的时候我首先看的是《领域驱动设计-软件核心复杂性应对之道》，这本书里记录了很多概念，方法，思想，策略，模式等。整体读下来非常费劲但是收获也不小，如何转化为自己的能力就需要深入揣摩了

总纲图1 总纲图2 一、MODEL-DRIVEN DESIGN语言的导航图 二、模型完整性模式的导航图 三、一些有助于获得柔性设计的模式导航图 四、一些大型结构模式导航图 五、战略精炼的导航图 六、大

我这边准备通过自己的学习和落地经验跟大家分享一些关于DDD相关的知识，因此今年会写一些DDD主题的公众号文章。欢迎大家关注。