《领域驱动设计：软件核心复杂性应对之道》读书笔记 ( 二 )

╰半橙微兮° 2022-01-27 07:13 222阅读 0赞

有那么个观点:写出计算机能动的代码,傻子都能做到,但是写出人能懂的代码,很难了,尤其很长时间之后,别人能看懂,能修改的代码.可以说还算比较正确吧.

总结:貌似没办法写出一个总结来,因为东西太散了,要说一定有个核心吧,就是**高内聚,低耦合**,本书一直致力与此.

交流语言的使用,使用专家和开发人员都听得懂的语言进行交流,不行就找个中间人进行交流.

使用通用语言.

专业人员和开发人员的交流,而不是通过一个产品经理来进行沟通,因为现在有的产品经理不会写代码,他完全不懂一个功能后面的代码量和复杂程度,有的会一味讨好客户,只要他们说的,就写文档让开发进行实现,其实有点没必要了.有时候不一定需要那么个功能,只是为了一个很小的目的,只是那些专业人员表示不出来,才那么说,挖掘客户的真正需求,想要什么东西.

改善模型的最佳方式之一就是通过对话来研究,试着大声说出可能的模型变化中的各种结构.这样不完善的地方很容易被听出来了.

架构设计的时候,要大声的把自己的疑虑,以及未来可能遇到的变化都说出来.大家一起讨论,不要一言堂

画的UML图,主要以类图和对象交互图为主,画图注意只要枝干,因为细节过多的结果就是”之间树木,不见森林”

UML和代码的作用是不同的, 不要用UML生成代码. 代码想好了再写,不要先写,再想怎么设计….这样就要返工了.

软件架构普遍使用的是layered Architecture(分层架构),有:

用户界面层

应用层

领域层

基础设施层

这就是典型的高内聚,低耦合了

在每一层内分别进行设计,使其具有内聚性并且只依赖于它的下层.

依赖的传递

三种模型元素模式:Entity, Value Object, Service

Value Object 我们只关心他们是什么,而不关心他们是谁.

Value object只是作为一个数据结构来方便使用的,

Service 应该是无状态的.

是的,不然很容易产生一些脏数据什么的,尤其在高并发的状况下,错误也很不容易排查出来.

Module 之间应该是低耦合的,而内部则是高内聚的.

对象建模在简单性和复杂性之间实现了一个很好的平衡.

对象建模把现实和模型对应起来了, 容易理解很多, 现在有了函数式编程,抽象度更高,也有一些借鉴的地方

Fatory模式

Entity Factory 与 Value Object  Factory的选择,以及对象的生成,进行解耦

都可以有工厂模式,创建和使用解耦

重构:

源于对领域的新认知,能够通过代码清晰的表达出模型的含义.

为了更好的满足需求.

重构的原则是始终小步前进,始终保持系统的正常运转.

为了使项目能够随着开发工作的进行加速前进,而不会由于它自己的老化停滞不前,设计必须要让人们乐于使用,而且易于做出修改.这就是柔性设计(supple design)

易修改的模式,对扩展开放,对修改关闭.

如果一个开发人员为了使用一个组件而必须要去研究它的实现,那么就失去了封装的价值.

我觉得为了了解开源的高深而去学习,还是不错的. 不过现在的一些东西确实有点太复杂了.应该简化点.

任何对未来操作产生影响的系统状态改变都可以称为副作用.

引入fp中的纯函数概念.

开发人员必须限制”组合爆照”,这就是限制了系统行为的丰富性.

组合优于继承,能使用组合的时候,不要使用继承,继承和实现的体系必须严格,进行呈现线性的结构.

尽可能的把程序的逻辑放到函数中,因为函数式只返回结果而不产生明显副作用的操作.

从单个方法的设计，到类和Module的设计，再到大型结构的设计，高内聚，低耦合，这一对基本原则都起着重要的作用。

低耦合，是对象设计的一个基本要素，尽一切可能保持低耦合。把其他所有无关概念提取到对象之外，这样类就变得独立了，这就使得我们可以单独的研究和理解它。每一个这样的独立类，都极大地减轻了应理解Module而带来的负担。

我们的目标不是消除所有依赖，而是消除所有不重要的依赖。

是的,消除不必要的存在,不然徒增系统的复杂性.

尽力把最复杂的计算提取到独立的类中, 实现此目的的一种方法，是从存在大量依赖的类中将value object建模出来。

低耦合是减少概念过载的最基本方法，独立的类是低耦合的极致。

建模的不断修改,不断调整,得到最适合的模型.

不断的思考,不断的优化

为了在领域驱动设计中充分的利用这些设计模式,我们必须从两个角度看待他们,从代码的角度来看他们是技术设计模式,从模型的角度来看他们就是概念模式.

不同的角度看问题,了解使用.

策略模式.不同场景下选择不同的的实现,(来自同一个规则)

如何找到问题的病灶往往是最难和最不确定的部分.

一个模型只在一个上下文中使用.

两个系统的接口对接,可以在其中加一个中间层,作为中间件来进行两个系统的交互,也可以使用rpc或者http的方式来进行,

逐步淘汰遗留系统

好花美丽不常开,好景怡人不常在.(翻译也是个文艺的人)

一个严峻的显示是我们不可能对所有涉及部分进行同等的精华,而是必须分出优先级.

先弄最重要的东西,再次之

编写一个非常简短的文档,(3-7页,每页内容不必过多), 用于描述 core domain 以及core元素之间的主要交互关系.

200页的文档,谁也不想看啊,看着也累啊,写文档有总结.

把主要模型的主要储存库中的ecore domain标记出来,不用特意去阐明其角色.

最关键的业务模型是什么?

选择重构目标:

1.如果采用”哪儿痛治哪里”这种重构策略,要观察一下根源问题是否涉及core domain或core 与支持元素的关系.如果确定涉及,那么就要接受挑战,首先修复核心.

2.当可以自由选择重构的部分时,应首先集中精力把core domain 更好的提取出来,完善对core的分离,并且把支持性的子领域提炼成通用子领域.

哪里最重要?哪里才是最需要修改的地方?哪里是修改最多的地方,最混乱的地方

创建一组不同的对象,用他们来描述和约束基本模型的机构和行为,把这些对象分为两个级别,一个是非常具体的级别,另一个级别则提供了一些可供用户或超级用户定制的规则和知识.

80%/20%的原则.

从接口和交互中提炼出一个abstract core ,并创建一个框架,这个框架要允许这些接口的各种不同实现被自由替换.

里式替换原则. Java SPI的接口和实现的分离.就行解耦合.

发表评论取消回复

表情：

评论列表（有 0 条评论，222人围观）

还没有评论，来说两句吧...

相关阅读

相关复杂性应对之道 - 领域建模

原文地址：[http://www.uml.org.cn/sjms/201812133.asp][http_www.uml.org.cn_sjms_201812133.asp]

怼烎@/ 2022年12月13日 04:18/ 0 赞/ 227 阅读

相关解构领域驱动设计（一）：为什么DDD能够解决软件复杂性

1 为什么我要研究领域驱动设计 1.1 设计方法各样且代码无法反映设计我大概从2017年10月份开始研究DDD，当时在一家物流信息化的公司任职架构师，研究DDD的初

今天药忘吃喽~/ 2022年10月17日 01:50/ 0 赞/ 172 阅读

相关领域驱动设计之领域模型

2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域

蔚落/ 2022年08月19日 14:19/ 0 赞/ 238 阅读

相关领域驱动设计

有幸参与了一些领域驱动的项目，读了一些文章，也见识了一些不伦不类的架构，感觉对领域驱动有了更进一步的认识。所以今天跟大伙探讨一下领域驱动设计，同时也对一些想要实践领域驱动设计却

喜欢ヅ旅行/ 2022年05月22日 09:52/ 0 赞/ 301 阅读

相关领域驱动设计之领域模型

加一个导航，关于如何设计聚合的详细思考，见[这篇][Link 1]文章。 2004年Eric Evans 发表Domain-Driven Design –Tackling C

深藏阁楼爱情的钟/ 2022年05月22日 09:47/ 0 赞/ 371 阅读

相关领域驱动设计笔记

通用语言：通过团队交流达成共识的能够简单清晰准确传递业务规则的语言（可以是文字、图片等）即可称为通用语言。领域：一个领域本质上可以理解为就是一个问题域，只要

谁践踏了优雅/ 2022年04月25日 06:02/ 0 赞/ 552 阅读

相关软件复杂性简洁之道 - 设计原则篇

![image.png][] 前言软件之所以这么有魔力这么繁荣，在于软件的灵活性，也正因为软件的灵活性导致了软件的复杂性。绳子灵活而方便，它能360度无死角花样系东西

男娘i/ 2022年02月13日 20:13/ 0 赞/ 262 阅读

相关《领域驱动设计：软件核心复杂性应对之道》读书笔记 ( 一 )

其实在写这个的时候,书不在边上,就随便写点吧. 书基本上已经完成了通读一遍了,说实话,就前几章的内容觉得自己看懂了一些,后面的越看越迷茫不知道这本书写了些什么,要表达什么.

女爷i/ 2022年01月30日 19:39/ 0 赞/ 247 阅读

相关《领域驱动设计：软件核心复杂性应对之道》读书笔记 ( 二 )

有那么个观点:写出计算机能动的代码,傻子都能做到,但是写出人能懂的代码,很难了,尤其很长时间之后,别人能看懂,能修改的代码.可以说还算比较正确吧. 总结:貌似没办法写出

╰半橙微兮°/ 2022年01月27日 07:13/ 0 赞/ 223 阅读

相关领域驱动设计读书笔记-术语介绍

本文为极客时间《DDD实战》的读书笔记 DDD-基础 DDD基础介绍微服务设计和拆分的困境对于微服务的拆分粒度很模糊，不知道业务或者微服务的边界是什么，

拼搏现实的明天。/ 2021年09月18日 07:26/ 0 赞/ 453 阅读