《领域驱动设计》重读感悟

Posted 2021-05-01 dumpcache极客技术

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了《领域驱动设计》重读感悟相关的知识，希望对你有一定的参考价值。

我觉得在创业公司对系统的设计其实越要谨慎，不能因为只求快速而忽略了一些基本的设计要求，导致后续一个烂摊子不好收拾。最近几日抽空重读了Eric Evans的《领域驱动设计》，感悟记录如下。

记得上一次读这本书已经是十年前的事情了，当时还是个没有经验的菜鸟，看这种书似懂非懂，况且翻译又有些糟糕，其实根本没看懂。经过这十年的成长，而且读了大量非技术类的方法论书籍，感受到，知识其实是想通的，任何其他领域的经验都是可以在本领域得到复用和验证的。

言归正传，说说《领域驱动设计》这本书，我把总结归纳为4个部分。

一.大多数书籍的第一部分都是提纲挈领式的纵览全局，然后提出全书的中心思想，本书也一样，作者一开始就提出了领域建模的思想，并且强调其重要性，在建模过程中，必须要有统一的建模语言，尽量精简抽象，能统一和表达意，另外不要割裂建模和编码这两个过程，否则会让模型和实现越走越远。

其中，建模语言统一非常重要，描述的工具可以是很简单的画线框图，只要能表述问题就好，但是概念必须统一，比如描述一个商品，有人叫product,有人叫item，那就比较麻烦，必须选一个大家都能接受的来统一概念。

二.本书的第二部分是教授大家领域建模的方法。这部分，我认为可以分为3块来理解。

1）分层设计的思想，这也是计算机领域的通用思想，当一个层无法解决问题的时候，可以引入新的一层来描述相关问题。

作者把大部分的应用都分为下面4层：

--用户界面

--应用层

--领域层

--基础设施层

2）领域层是软件的精髓，在构建领域层的过程中，就是找到对象间的各种关系，无非就是，关联-组合-聚合等。这块我觉得可以结合UML中画类图的方法来理解一下。

3）构建领域模型，找准各种对象的定位：

a)最为核心的就是找到实体

b)不要搞混值对象和实体概念

c)把功能暴露出去的是服务

d)大型软件必然是功能复杂多样的，把职责相同的功能内聚在同一个模块中，这也是体现高内聚的思想。

e)某些对象构建较为复杂，为屏蔽用户关注这一细节，可以采供工厂的思路。

f)假如有长期存在对象要经常使用，或者存在序列化/反序列化的需求，我们要对其进行管理，可以采用资源库的思路。比如数据库层面我们经常使用的DAO就是一个资源库。

另外，这部分还可以参考四色建模法的思路，来构建领域模型。

四色建模法(Color UML)是由Peter Coad 发明的一种建模方法，将抽象出来的对象分成四种原型（archetype）：

1、moment-interval,这种对象表示那些在某个时间点存在，或者会存在一段时间的，这样的对象往往表示了一次外界的请求，比如一次询价（Quotation），一次购买（Sale），这样的对象表示的都是系统的价值所在，所以也是最重要的一类对象，一般用粉红色来表示。这样的对象一般都有一个起始时间和终止时间，以及一个唯一的标识号，用来唯一的标识这一次客户请求，比如PolicyNo.

2、Role，这种对象表示的是一种角色，往往由人或者物来承担，会有相应的责任和权利，一般一个moment-interval对象会关联多个Role,比如说一次询价（Quotation）涉及到两个Role, 询价人（Quoter）和询价的产品（Product for Quotation）, 这类对象是除moment-interval对象外最重要的一类对象，一般用黄色来表示。这类对象一般都有一些被moment-interval对象请求的操作，用来完成它们的职责。

3、 Party,Place, or Thing, 这种对象往往表示的是一种客观存在的事物，例如：人，组织，产品，配件等等，这些事物往往会在一种moment-interval 中扮演某个Role, 比如某个人会在一次购买中扮演Customer的角色，也可以在询价中扮演询价人的角色。这类对象第三重要，所以一般用绿色来表示。这类对象一般都有Name,Address等属性。

4、Description，这种对象一般是分类用或者描述性的对象，一般某个Thing,Place，Party会属于某个Description，主要用来表示一类事物，它的属性一般都是这一类事物都有的属性，这类对象一般用蓝色来表示。这类对象一般都有type,defaultValue等属性。

通过将分析得到的领域对象分别归入这四类原型，能让我们更加深刻的理解每个对象的职责，以及对象之间的相互关系，通过四种颜色，能表达出比一般的黑白模型更加丰富的领域信息。

另外，要强调的是，再牛逼，再经验丰富的设计师，也没法对业务理解一步到位，领域模型不可能一次设计就永久不出现问题。所以重构是在所难免的，而且，贯穿项目生命周期的始终，只要你想，就可以重构。

三.书中的第三部分针对大的系统，特别是需要协作的系统，提供了战略性设计的思路和解决方案：

要找准各自系统的定位，找到系统边界，划分各自的领域。
某些有交集的系统，可以采用共享内核的思路，来全局设计一个共享内核，然后让各自团队开发周边功能。
有部分协作类似客户-供应商的模式，两个团队应该经常相互沟通，互相理解需求，不要各自为战。
顺从者，有时候供应商的软件做的非常好，那么我们只要简单的顺从就行了。
防崩溃设计，假如对方的软件是个黑盒，你也担心它的稳定性，并且害怕对象侵入你的系统，破坏你的设计，可以通过单独设计一层代理与对方沟通，保护自己的系统边界，就像万里长城一样。
独立方法，假如一个企业都是由很多小应用组成，并且各自关联不大，可以各自独立设计。
开放主机，假如你的系统有很多子系统要暴露给别人，那么建议单独设计一层服务暴露层，然后定义专门的通信协议，防止对象需要针对你不同的子系统进行集成接入。