共计 2768 个字符，预计需要花费 7 分钟才能阅读完成。
哈喽哈喽大家猴，我是把代码写成 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 性能调优学习材料。
