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

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

 

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

 

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

使用通用语言.

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

 

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

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

 

画的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的接口和实现的分离.就行解耦合.