哈喽哈喽大家猴，我是把代码写成bug的大头菜。公众号：大头菜技术(bigheadit)。原创不易，但欢迎转载。

这周总得来说，大头菜比较忙，但也不忘学习。这周主要学习了领域驱动设计DDD。为什么学这个东西，因为最近大头菜和一位大佬L讨论需求设计时，大佬L指出我做接口设计时，太过于从代码出发，做的东西可以符合一次需求，但是没沉淀，无法解决更多同质问题，

虽然我做的项目是分布式项目，但是我的思考方式却停留在单机架构：整个系统围绕数据库驱动设计和开发。这其实很显然就是思维上的停滞和懒惰。表面上你做的是分布式项目，但本质设计和开发还停留在单机架构。我相信不只我一个人是这样子的，你也可以反观一下自己哈哈哈。

面对这困局，我深知自己急需破局。我需要从思维层面上，从面向数据库设计和开发，转变到领域建模实战。

我自己看的书籍是领域驱动设计。目前看了一些DDD的基本概念。下周可以继续看进阶篇，如果不忙，应该可以直接到实战部分。看吧，下面是我看DDD时，自己整理的一些疑惑和笔记。

DDD笔记

1、DDD的用途？

A:用来指导中台和微服务的设计

2、中台，DDD和微服务三者的关系

A:中台本质是业务模型，微服务是业务模型的系统落地，DDD 是一种设计思想，它可以同时指导中台业务建模和微服务设计，它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。

3、微服务拆分困难的原因

综合来看，我认为微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。

DDD就是用来指导微服务拆分的指导思想。

4、DDD是什么？

DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。

5、总结

面对复杂问题，解决办法通常是拆分，模块化，化整为零。领域驱动建模DDD是面向业务，对业务领域的划分和整合，是逻辑层面。微服务是面向物理落地，是对应用的物理形态进行拆分和整合。从软件工程过程角度看，DDD的战略设计输出物，领域模型及划分的区域，是微服务的输入，一个区域对应一个微服务，微服务运行框架、平台可以承载所有的微服务，提供微服务统一的运行框架，也就是承载所有的业务领域。可见领域驱动与微服务是在软件不同阶段使用的工具，技术或方法论，围绕一个共同的目标，搭建企业业务中台，企业级业务复用，快速的需求响应能力。DDD战略设计得输出，是微服务的输入。

6、领域

领域就是范围。DDD就是不断强调范围，强调边界。

7、子领域

领域进一步划分就是子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。

8、子域的分类

在领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。
核心域成功的关键，通用域是可以买的，支撑域是可以外包的

9、什么是通用语言

在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言

10、DDD 分析和设计过程中的每一个环节都需要保证限界上下文内术语的统一，在代码模型设计的时侯就要建立领域对象和代码对象的一一映射，从而保证业务模型和代码模型的一致，实现业务语言与代码语言的统一。

11、为什么要提出限界上下文

为了避免同样的概念或语义在不同的上下文环境中产生歧义，DDD 在战略设计上提出了“限界上下文”这个概念，用来确定语义所在的领域边界。

举个例子：
在一个明媚的早晨，孩子起床问妈妈：“今天应该穿几件衣服呀？”妈妈回答：“能穿多少就穿多少！”那到底是穿多还是穿少呢？如果没有具体的语义环境，还真不太好理解。但是，如果你已经知道了这句话的语义环境，比如是寒冬腊月或者是炎炎夏日，那理解这句话的涵义就会很容易了。所以语言离不开它的语义环境。

理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。

12、什么是实体

对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的对象称为实体

13、什么是值对象

值对象描述了领域中的一件东西，这个东西是不可变的，它将不同的相关属性组合成了一个概念整体

14、实体和值对象的区别？

实体着重唯一性和延续性，不在意属性的变化，属性全变了，它还是原来那个它；值对象着重描述性，对属性的变化很敏感，属性变了，它就不是那个它了。

生产事故——磁盘使用率爆满

已经专门写了一篇文章来描述磁盘使用率爆满事件，直接进去看就好，这里就不重复了。
生产事故——磁盘使用率爆满

分享一些工作中的趣事

我就瞎聊了。

最近我做了一个修改商家别名的需求。一个商家有多条业务线，比如有送外卖的，有租车的，每一条业务线都允许有不同的别名。在这个大背景下，需求就产生了。一开始这个需求很快设计、开发、提测、上线，真是一气呵成啊！然而，上线后，发现很多其他下游系统都有调用这个接口，比如C端的商家列表页，详情页，后台的列表页。。。。这个需求一共前前后后，上线了3次，才把坑填好。有人会问，不能保证接口返回值一致吗？其实，我已经保持一致了。但这次因为允许每一条业务线都有商家别名，需要换表。以前的接口，是从缓存中查询别名的，现在的接口，已经换表了，直接怼数据库。因为数据量不大，没必要中间加缓存了。

第二件事：我和我后端同事R对接接口，我的返回值，先说明，永远不可能为null的。但是呢，我同事R调我的查询接口，说日志打印了null值。接受过九年义务教育的我，都是先反思自己，再去怀疑别人。于是乎，我就把我的代码从头到尾看了一遍，发现都不可能给他返回null。我也看了一下我这边的日志，发现，非常正常呀，都是返回一个JSON值给他。但他那边的日志又确确实实是Null值。害！那时候我已经觉得自己疯了，就在我准备放弃前，我要求看看他的代码。代码如下：

List list = null;

XXXService.getList();

log.info(JSON.toJSONStirng(list))

看到这里，我破口而出：哥，你都没赋值，没赋值。我当时都结巴了，因为实在哭笑不得。好气又好笑！！！

老司机滑铁卢了！！！！

今天就聊到这了，简单地复盘了一下上周的工作和生活。想问个问题，清明节快到了，你们被人祝福过清明节快乐吗哈哈哈哈！

福利

公众号后台回复:性能优化 可领取相关JVM性能调优学习资料。