领域驱动设计:软件核心复杂性应对之道_程序员的自我修养：DDD 领域驱动设计...

程序员的使命，软件定义世界。

如何理解我们周遭的世界？

如果你手里有一把锤子，所有东西看上去都像钉子

每一种思维模型都是理解世界的一种方式。

然而局限于各种思维模型容易产生盲人摸象的局面。

比如 学完 MySQL，如果要开发图书管理系统，首先就是设计表结构，如何符合数据库的范式 ... 接着就是简单的 CRUD ，如此两三年后，也就认为编程也就是如此了。

如此导致编程的思维僵化，技术的发展也就止步不前。

一般来说，程序员的科技树如下：

• 架构师
• 算法专家
• 领域专家

架构师：不过在云计算产业如此发达的情况下，大部分中小企业其实是不需要架构师的。

云计算已经承担了大部分的风险，使得业务开发门槛降低，所以程序员只能做一些微小的优化。

算法专家： 这里有工程方面的也有业务方面的，工程方面比如负载均衡的算法，业务方面如推荐算法。这条路对心智水平要求要高一些，要担心 “我秃了，但我更强了。” 的局面。

领域专家：也就是各行各业不同软件的业务不同，比如电商、快递、工业流水线，需要程序员学习这个行业的领域知识，这也就是不同行业的程序员千差万别如此之大的原因。这也是 80% 的程序员的打怪之路。

当然，程序员职业发展不是非此即彼，而是此多彼少。 其实架构师有的时候干的就是运维的活，只不过有人觉得自己是高贵的开发，不屑于弄懂它。于是很多解决难题的学习机会就如此的错失了，也就错失成为架构师的锻炼机会。

OK， 接着讲领域驱动设计，首先什么是领域知识呢？

举个例子：

• 有借必有贷，借贷必相等。
• 秒杀
• 做帽
• 天王盖地虎
• 爆仓

不同行业的领域知识千差万别，这就是为什么程序员要不断学习的原因，并且要深耕于某个领域，直到自己成为领域专家。

对领域知识学习之后，如何设计这个领域的软件？
我们要打破既有认知， 做一个思维实验：

“假如内存无限大，你会如何设计你的软件？”

这个时候，我们根本不需要 MySQL ，思维不必受限于什么狗屁范式。

而将心智全部用于描述这个世界和这个领域系统，不要在意细节。

驾驭复杂领域的软件设计，只有一条康庄大道：

IT’S ALL ABOUT ABSTRACT 这全都是关于抽象。

抽象的示例：

• 分层抽象: 如 TCP/IP
• 抽象屏障：如 我牵着狗走路，而不是牵着狗的腿走路。
• 控制流&数据流分离：微服务的注册与发现的机制

领域驱动设计的分层设计：

领域驱动设计的描述：

领域驱动设计的名词解释：

• 实体 vs 值对象
• 服务 Service
• Repository
• 聚合根 Aggregate

实体这个概念很好理解，对 CRUD 程序员来说，实体就是有 ID 的对象。

值对象，比如 颜色之类，数字就是值。

服务，相当于接口。比如一个插座提供的是充电的服务。

Repository，这是用来管理实体的生命周期的一个 Manager 概念。

聚合根，这是将多个对象包装起来对外提供的隔离屏障，比如 我牵着狗走路，狗相当于聚合根，对我来说，我不关心狗的腿是怎么行走的。我只是通过绳子来指令狗这个实体来走路。

对领域驱动设计这种思维模式稍有理解之后，可以尝试一下，将其用在微服务治理。

或者阅读 《领域驱动设计：软件核心复杂性应对之道》了解更多。