轻松DDD之学二:如何高效消化知识
我是2012年开始接触DDD的,后续研读过几遍《领域驱动设计:软件核心复杂性应对之道》,也用DDD做过项目。总的感受是DDD的一些概念比较晦涩难懂,很难掌握,因此想写个系列短文,希望能帮助大家更轻松地理解DDD。文章很多都是我个人体会和理解,难免有错误,希望大家能及时指正,共同探讨提高。前面短文链接:
轻松DDD之学一:模型驱动设计
本文是系列短文第二篇,介绍<强>如何高效消化知识。
1。知识来源
在讲如何消化知识前,我们要明确下建模的知识来源有哪些。首先我们通过下图来考察模型,领域,软件,现实世界,计算机系统等几个概念的关联。
-
<李> <>强现实世界(蓝线左半边)和计算机系统(蓝线右半边)。我们把用户需求理解为用户要求我们构建一个特定的计算机系统,通过它用户能按自己的期望来改变现实世界,比如淘宝网就是一个这样的计算机系统,通过它阿里巴巴可以让商品销售变得更快捷,更方便,成本更低。
<李> <>强领域和软件。强领域就是用户需求和从用户需求这个视角出发对现实世界的认知集合;软件就是可以让计算机系统按照用户期望方式来运转的程序。
<李> <>强领域模型。它富含领域知识,与实现绑定,能够把领域和软件有效地耦合起来,从而能够让我们基于模型快速开发功能丰富的软件产品。
从上面的认知我们可以知道<强>模型就是在用户目标和软件实现技术的约束下对领域知识的精确化,结构化和抽象。
2。知识消化
由于建模依赖于在用户目标和软件实现技术约束下的领域知识梳理,因此建模就要求领域专家,建模专家和软件开发之间通过高效地沟通协作来有效地消化领域知识。下面我们从沟通媒介,沟通形式和目标三个方面来展开说明如何做到这一点。
2.1沟通媒介
消化知识的沟通媒介可以是多种多样、下面是几种主要的沟通媒介:
-
<李> <>强口语:这是人类最擅长的沟通方式,成本低廉,形式丰富,是埃里克最为推崇的沟通手段。
<李> <>强文字:擅长精确表达,同时与口语的转换也非常方便。我们用文字来记录模型中最重要的概念,行为,规则的定义和解释。
<李> <强> UML :图形形式的UML非常擅长表达对象间的关系和交互,也能有效地指导OO语言的代码编写。但是它不擅长概念的定义,也难以表达对象的行为和约束,需要与文字说明配合.UML图包含了大量的实现细节,大家很难基于它们做高效沟通,同时创建维护它们需要大量的工作量,因此我们往往用简单的非正式的UML图作为讨论的主题。
<李> <>强代码:通过代码表达业务细节可以让我们节省大量的文档编写维护的工作量;同时如果代码能够让领域专家容易理解乃至编写,也可以让模型能更好地与实现绑定。但是代码往往充斥实现细节,难以表达整体的,大比例的模型知识。
<李> <>强解释性模型:用户驱动软件开发过程的技术模型必须经过严格的精简,受到严格的限制,因此基于技术模型学习领域知识效率很低。解释性模型则没有这些限制,用它可以更快更好地理解领域知识。
总体来讲,我们应该以口语为主要沟通手段,用文字定义重要的领域对象,约束和行为,用简化的非正式UML图表达领域对象间的关联和交互,用代码来承载设计细节,用解释性模型来加快领域知识的学习。
2.2。知识消化的沟通形式
有了沟通手段,我们还需要沟通形式,下面是一些主要的沟通形式:
-
<李> <>强头脑风暴。当一群人围绕一个特定的兴趣领域产生新观点的时候,这种情境就叫做头脑风暴。头脑风暴通过参与者之间充分的思想碰撞来激发新观点和解决方法,因此非常适合在建模初期使用。头脑风暴具体展开形式我们可以采用以简化的UML图为主题,一边讨论一边精炼的方式,也可以采用现在比较流行的<强>事件风暴强方式。
<李> <>强场景走查。我们可以基于模型来走查各种场景,以便确认模型能够很好地表达和实现各种场景。场景走查是一个成本低廉的试错手段,通过它我们可以避免由于不合理的模型造成软件开发的返工。
