领域驱动设计 - 读笔一

读书笔记/ 领域驱动设计

创建时间:2019-08-28 16:45

字数:1.5k 阅读:

评论:

序

很多因素会使得软件开发复杂化，最根本原因是问题领域本身错综复杂。

抓住复杂性的关键是有一个好的领域模型。

领域模型的最大的价值是它提供了一个通用语言，将领域专家和技术人员联系到了一起。

模型其实在迭代设计的过程中不断的改变，成为项目不可分割的一部分。

其实 DI 的模型就一直在变化，从最开始的只有报表，图表；到后面加入了工作簿的概念；到做开放，有了应用的概念，将查询接口与图表解耦等等。模型在不断变化或者优化解耦，代码如果不紧随着整体变化，而只是变化表象的部分，会导致项目内部越来越乱！

没有一个统一的，有共识的结构化的模型，会让项目过早的僵化，最后变成维护代价极高的遗留系统。然后就 2.0，3.0 的更新换代。

当复杂性失去控制的时候，开发人员就无法理解软件。当领域的复杂度没有得到解决时，基础技术再好的构思也无济于事。

领域模型是开发人员和领域专家交流的结果，是一个反映深层次领域知识并聚焦于关键概念的模型。

为了创建真正好用的软件，开发者必须有一整套与活动有关的知识体系。为此要知道的广度可能让人生畏。于是出现了模型，模型就是解决此类信息超载问题的工具。模型将知识选择性的简化和有意的结构化，让人们理解信息的含义，并专注于问题。

领域模型的作用：

很多情况下并不能引起重视的原始是，开发人员往往对学习与他们工作领域有关的知识不感兴趣。他们喜欢能够提高其技能的可量化问题。

这里想到导演说过的我们不仅仅是前端，我们的竞争力在于我们是数据前端，我们的竞争力会在于我们对于我们数据业务的理解。

理解领域核心的领导者能够将软件项目带到正确的轨道上。

记得之前我做 x-table 的时候，找翎一评估我的设计，他最开始评判的角度不是看我的技术方案能够实现，而是我做的符不符合现在的模型。不时刻关注的话很容易迷失方向，是的项目丢掉了整体感，丢掉了系统完整性。

程序员不去了解领域，只去了解程序应该有的功能。虽然也能开发出可用的软件，但是项目永远也不会从原有特性中自然扩展出强大的新特性。领域模型的不断精化迫使开发人员学习重要的业务原理，而不是机械的功能开发。领域专家也会被迫提炼知识，完善自身理解，也会渐渐理解软件项目必须有的概念严谨性。

产品和开发的认识都会受益升华。

看起来没什么难度的领域模型很可能是一种错觉。

所有的项目都会丢失知识。外包出去的系统可能只交回了代码。知识没有传递回来。离职了，转岗了，一旦出于某种原因人们没有口头传递知识，知识就丢失了。

这一点挺可怕的，丢失的知识会导致越来越难维护。

请注意，研究领域模型的目的不一定是要成为业务上的专家。而是我们要能够与之沟通并且理解主要概念，并且有检查内容是够合理的能力。

作者在这里举了个小例子，一个功能点在实现上可能就是乘以一个系数，很容易让人忽略，其实他背后对应了业务意义。举这个例子的目的是模型和对应的设计可以保护和共享知识。

虽然其实大部分模型都是后端在建立，但是前端是可以协助思考优化，并且借鉴着设计前端项目的，来保证系统的整体的感受。

将模型作为语言的支柱，交流和代码中都坚持使用这种统一的语言。画图，写东西，都是用这种语言。

图是一种沟通的手段，我们要避免画包罗万象的对象模型图。互为补充的图和文档能够让人们将注意力集中到核心上。

我最开始为了创建领域模型画的图就不对，内容太多，反而没起到图该有的效果。

务必要记住模型不是图，图是为了表达和解释模型。对设计起到推动作用的模型是领域的一个视图。

代码作为设计文档的坏处是可能会把读代码的人淹没在细节中。尽管代码是明确的，但是行为不一定是的，行为背后的意义可能难以表达。并且开发人员不是唯一需要理解模型的人。

文档如果不再担负重要的作用，那么靠意志和纪律保持更新就是浪费精力。

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 981909093@qq.com