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

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

书中主要介绍了我们对于业务的处理,个人感觉就是在讲设计模式的演进,只是很零碎,里面也穿插了非常多的东西.
书中的主线一直都是把 高内聚,低耦合 作为设计的不断演进目标.
书中主张技术开发,不仅需要把代码写好,还要不断的去了解业务,不断的推进针对实际业务的模型优化,不断的堆代码进行优化,重构,以实现对业务的最好表达.(道理TMD我都懂,关键是书里说不断的重构,不断的优化,有时候我也想停下来把代码好好的优化下,看看有什么更好/更快的方式完成,但是臣妾做不到了,不要问我为什么做不到,你要是个开发就知道了)

其实书中的一些观点很正确,像改变 客户-产品-开发 的这种三段式结构,改为  客户-开发 二段式结构,又开发深入的去了解业务,知道客户需要什么?而不是看一个产品的翻译,会损失很多的东西.
开发人员不应该天天想着用什么技术,而是更加深入的去了解业务的走向,需求,而不是只是不断的提高自己所认为的技术,技术和业务对于开发同样重要.

例如书中提到框架,说框架是解决一些复杂的技术问题的,但是也不要被框架束手束脚了,
我们确实使用框架解决一些重复性的工作,让我们能够快速的实现业务的需要,不过也衍生了第二方面的问题,
需要专人去维护基础设施的框架,一部分人专门做底层基础设施,另外一部分人专门去实现业务,两者相互配合.

书中写单例模式,使用的是造汽车的例子,一个汽车作为一个entity , 我们不应该把汽车的建造过程放在这个entity中.而是单独的拿出来.

例如一个复杂的算法,也应该抽离出来,这样就很容易对应上策略模式了,不同的场景使用不同的具体算法...

书中关于entity和value object 的解释,entity 的存在大多是具有唯一标示的,其实就是分布式环境下的唯一id,而value object 只是作为一个接受结果的数据类型的存在,定义使用起来就很随意的了,但是建议是用不可变的属性,就是private final int id......, 达到只是作为结果接收的效果,不能随意去改变.

暂时就先写这个多了,下次再写.

2019年5月19日21:45:11