大家好大家好，我是写代码成bug的萝卜。公众号:大头。原创不易，欢迎转载。总的来说，这周大头菜比较忙，但也不忘学习。这周主要学习了领域驱动设计DDD。为什么要学这个东西，因为最近Rutabaga和一个大老板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.什么是共同语言？事件风暴期间，通过团队沟通达成共识，能够简单、清晰、准确地描述业务含义和规则。Languageisthecommonlanguage10.DDD分析设计过程中的每一个环节都需要保证限界上下文中术语的统一性。在设计代码模型时，需要在领域对象和代码对象之间建立一对一的映射关系，从而保证业务模型与代码模型一致，实现业务语言和代码语言的统一。11、为什么会提出BoundedContext？为了避免相同概念或语义在不同上下文中产生歧义，DDD在策略设计中提出了“限界上下文”的概念，用于确定语义所在的领域边界。例如：在一个晴朗的早晨，孩子起床问妈妈：“今天我穿几件衣服好？”妈妈回答说：能穿多少就穿多少！那我应该多穿还是少穿？如果没有特定的语义环境，真的不好理解。但是，如果你已经知道这句话的语义环境，比如寒冷的冬天或炎热的夏天，那么就很容易理解这句话的意思。因此，语言与其语义环境密不可分。理论上的上界上下文是微服务的边界。我们将限界上下文中的领域模型映射到微服务，完成从问题领域到软件的解决方案。12.什么是实体？对于这些对象，重要的不是它们的属性，而是它们的连续性和标识性。对象的连续性和标识将跨越甚至超过软件的生命周期。我们称这样的对象为实体13.什么是值对象？值对象描述域中的事物，它是不可变的。它将不同的相关属性组合成一个概念整体14.实体和值对象的区别？实体注重唯一性和连续性，不关心属性的变化。如果所有属性都改变了，它仍然和以前一样；值对象注重描述性，对属性的变化非常敏感。如果属性改变，那就不一样了。ProductionAccident-Fulldiskusage已经写过一篇文章来描述磁盘满的事件，进去看看就可以了，这里不再赘述。分享一些工作中的趣事，我随便聊聊。最近提出修改商家别名的要求。一个企业有多个业务线，比如外卖、租车，每个业务线允许有不同的别名。在这种情况下，需求出现了。一开始这个需求很快就设计、开发、测试、上线，真是一口气搞定！但是上线后发现很多其他的下游系统都调用了这个接口，比如C端的商户列表页、详情页、后台列表页。...这个需求已经上线了3次才填坑。可能有人会问，接口的返回值不能保持一致吗？事实上，我一直很一致。但是这次因为允许每个业务线有一个业务别名，所以需要改表。在之前的界面中，别名是从缓存中查询出来的，而在现在的界面中，已经改表了，直接访问数据库。因为数据量不大，所以中间不需要加缓存。第二件事：我和我后端同事R对接接口，我的返回值，我先说明一下，永远不能为null。但是同事R调整了我的查询接口，说日志打印了一个空值。接受了九年的义务教育，我总是在怀疑别人之前反省自己。于是乎，我从头到尾看了我的代码，发现不可能返回null给他。我也看了一下我这边的日志，发现很正常，返回一个JSON值给他。但是他这边的日志确实是Null值。有害！那时我已经觉得自己疯了，就在我快要放弃的时候，我要求看他的代码。代码如下：Listlist=null;XXXService.getList();log.info(JSON.toJSONStirng(list))看到这里，我爆发了：兄弟，你没有赋值，你没有赋值。我当时结巴了，因为我哭不笑。又气又好笑！！！老司机在滑铁卢！！！！今天就到这里，简单回顾一下上周的工作和生活。想问一个问题，清明节快到了，你有没有过一个清明节快乐哈哈哈哈！福利公众号后台回复：性能优化可以获取相关的JVM性能调优学习资料。
