20210329-20210402技术周报

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

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

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

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

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

DDD笔记

一、DDD的用途？

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

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

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

三、微服务拆分困难的缘由

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

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

四、DDD是什么？

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

五、总结

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

六、领域

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

七、子领域

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

八、子域的分类

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

九、什么是通用语言

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

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

十一、为何要提出限界上下文

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

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

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

十二、什么是实体

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

1三、什么是值对象

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

1四、实体和值对象的区别？

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

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

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

分享一些工做中的趣事

我就瞎聊了。

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

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

List list = null;

XXXService.getList();

log.info(JSON.toJSONStirng(list))

看到这里，我破口而出：哥，你都没赋值，没赋值。我当时都结巴了，由于实在啼笑皆非。好气又可笑！！！

老司机滑铁卢了！！！！

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

福利

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