DDD中的建模与模型到底是什么意思？

软件研发的本质是为问题空间找到解空间的过程。

在问题空间中，我们要找出业务面临的问题与挑战，并结合需求场景进行用例分析。

在解空间中，就是采取具体的技术手段进行设计与实现。

领域模型就是针对于特定领域内的关键元素与信息进行可视化的表现。为了可以准确定义需要解决的问题，而进行模型的抽象构造，目的是为软件系统构建统一的认知。

总结来说，我们通过建模动作，生成模型。可以帮助我们分析与理解复杂的领域问题，也能更好的表现出涉及的元素与其之间的关系。

同时这种高度抽象的概念与定义，又可以变成研发与需求分析人员之间有力的交流工具，帮助做好需求的功能性分析，指导后续的架构设计。

DDD是解决复杂软件架构问题的方法论，其引入了一系列用于控制软件复杂度的手段，比如统一语言UL、业务抽象而非数据模型、领域划分限制问题域、领域建模分离业务与技术细节。

DDD可以分为战略设计与战术设计，前者以领域为出发点，后者主要用于建模。

这摆脱了过去很长时间基于数据模型为起点的软件架构思想，让软件架构设计的出发与演进可以更贴近业务，可以与业务发展同频。其软件架构所表现的是业务语义的显性表达，而不是简单的数据之间的关系。

DDD中的很多方法论已经脱离了编码本身，这某种程度上体现了一种全局思维。

比如UL，主要思想是让应用可以与业务相匹配，让业务与代码之间采用共同的语言表达。这样可以创造被业务、技术、代码理解的、无歧义的共同语言。

某种程度上可以实现BRD、PRD、设计文档、代码实现、团队沟通等多个层面的沟通效率与质量。

我觉得DDD另一个非常重要的意识革新是业务与技术的分离。

其实分离术在整个软件架构设计思想中无处不在，但只有上升到方法论层面，才更能让所有研发同学达成心底的共识。

技术与业务有着不同的演进路径，两者发展曲线的不同频，某种程度上导致了新的复杂度。

解决这种问题的简单方法就是分离，核心业务逻辑是整个应用的核心，而技术逻辑往往解决的是非功能性的高可用、高性能、定时任务、数据一致性处理等问题。两者之间没有依赖，也不应该有依赖。

对于业务内核来说，所有的技术依赖应该都是通过依赖倒置方式形成的，这种设计思想对于业务逻辑越复杂的系统来说，收益越高。

限界上下文也是DDD中一个非常重要的思想。

在其之前，我们做软件架构，主要用的是分层方式。就是按照功能作用将代码分层，每层做的事情是一样的，比如说MVC其实就是一种分层方式。

但对于复杂业务系统来说，简单的分层已经解决不了复杂度膨胀了，常见的是一个巨大的Service层，似乎所有与UI无关，与DB无关的逻辑都可以放到Service中。

而限界上下文在原有的横向分层方案中，引入了一个纵向的业务隔离。

业务内是业务强相关的所有逻辑，而不同业务之间要建立一道限界上下文。

常见的一个例子就是商品这个概念，其实你会发现商品在商品域、订单域、供应链域是完全不一样的。所以需要建立三个独立的域，域之间有清晰的限界隔离，商品的延伸概念要在相应的领域内放大价值才对。

限界与限界之间如果需要数据交互，不能领域内核之间产生依赖，可以引入防腐层实现通信。

所以对于DDD来说，在战略层主要的建模有三步：

1. 梳理业务相关的UL，只有清晰、无歧义的UL被所有的研发、产品、业务架构师达成共识之后，才可以将其应用于日常的需求评审、代码实现的细节中，无形中提升了需求沟通的效率与质量；

2. 技术与业务分离，不要将技术实现细节与业务实现细节耦合在一起，两者隔离的越充分越好，业务系统的演进要以业务内核为载体，所有的技术实现要被依赖倒置的方式引入；

3. 做好领域限界上下文的定义，所有的问题空间与解空间，只有在领域之内才更有价值，所有的概念与模型只有在领域之内才能更少的引发歧义，好的限界上下文应该可以做到领域随时以微服务的方式独立部署的效果才好；