DDD领域驱动设计落地实践系列：初识DDD

引言

DDD到底是何方神圣/h2>

软件设计方式

我们的软件开发模式可以分为几种类别，分别是DL驱动开发、数据驱动设计以及DDD驱动设计。实际上就是代表了我们不同的开发阶段，有种从粗犷到精细的阶段晋级的感觉。这就好比一个初入职场的萌新，到有一定经验的老鸟，再到精英的打怪升级过程。下面我们分别来看下这几种软件开发模式。

DDD

上文中通过不同软件设计方式的描述，引出了DDD领域驱动设计模式，那么我们就来看下DDD到底是什么。所谓DDD即Domain Driven Design，字面意思就是领域驱动设计。其实它并不是什么新鲜玩意，早在2004年著名建模专家Eric Evans在他的颇具影响力的书中《Domain-Driven Design –Tackling Complexity in the Heart of Software》（领域驱动设计：软件核心复杂性应对之道）已经提出来相应的概念。但是实际上国内各个互联 大厂能够把DDD应用好的并不多。
DDD不是一种架构形式，它是一种架构设计的指导思想，是一种应对复杂域问题的方法论。他可以协助我们设计高质量的软件模型。尤其是在复杂、大型软件系统的场景下，DDD尤其可以发挥其独特的作用。

我们除了理解DDD的知识，我们更希望在实际工作中运用这种软件架构设计的思想，但是这并非一件容易办成的事情。想要真正的落地实施DDD必须满足以下两个条件：

1、统一认识：DDD不是谁的独角戏，需要整个团队自上而下对于DDD有比较深刻的理解以及认同。虽然DDD是架构技术实践，但是其正向价值最终会传到业务端形成相应的业务价值。
2、贯彻实施：有了理论指导和深刻认识还不够，我们还必须在实际工作中进行贯彻实施，也许这个过程会有阵痛，但是只要熬过去，对于整个团队来说，必定是架构设计层面的一次跃升。

DDD重要概念

统一语言

秦始皇统一六国之后，首先做的就是在全国范围内进行了文字、度量衡、钱币的统一。其中统一文字，就是为了方便各个地域人们的沟通交流，为实现中国的大一统奠定了基础。

所以说领域模型就是针对某个特定业务领域的软件模型，如电商业务领域中的订单、积分、库存、配送等都是电商业务领域的子域。领域模型通过对象模型描述真实的业务场景，精确表达业务语义，它是实际业务场景中的流通货币。

在整个业务团队中，领域专家、设计人员、开发人员需要对领域模型有统一的认识，大家都认可。在不同的子域中就会有不同的领域模型，那么我们怎么来区分不同的领域模型呢，实际上就是通过限界上下文来进行区分。

限界上下文

这个概念怎么说呢，既好理解，又不好理解。限界上下文是一个显式的概念性边界，我们的领域模型都是此边界中，我们都知道领域模型是使用同一语言描述的软件模型，每个领域模型都有对应的属性和动作，这些属性和动作需要在一个特定的上下文环境中才有特定的意义。打个比方，笔记本在文具领域那么它就是一个纸质的记录工具，同样是笔记本这三个字但是在3C领域中，它指的又是我们常用的笔记本电脑。同样的名称但是在不同的边界上下文中代表的含义是完全不同的。因此实际上，限界上下文为团队创建了一个建模边界，团队成员在边界内部实现解决方案。

总结

大家好，我是慕枫，感谢各位小伙伴点赞、收藏和评论，文章持续更新，我们下期再见！

真正的大师永远怀着一颗学徒的心

微信搜索：慕枫技术笔记，优质文章持续更新，我们有学习打卡的群可以拉你进，一起努力冲击大厂，另外有很多学习以及面试的材料提供给大家。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91338 人正在系统学习中