首先，需要不断强调，DDD不是软件项目实施的银弹！！！
其次，我们该怎么理解领域驱动设计呢？下面我谈下我对此浅薄的见解。
在我们日常的项目实施流程中，可以抽象出两个重要组成部分。现实业务模型和计算机业务模型。现实业务流程模型，通常的表现形式，需求文档，流程图，各种标注的业务要点，存在于产品人员口头的说法和大脑里的想法，这些都是现实业务的模型组成部分和表现形式。计算机业务流程模型，通常的表现形式，一个或者多个计算机进程，各种内存对象，以某些算法实现的执行步骤和返回给用户的数据。项目实施的最理想的目标是，构建其和现实业务流程模型完美对应的计算机业务流程模型，从而高效的准确的实现业务方的需求。为了实现这个理想目标，项目实施中的各个角色都付出了极大的努力。应用软件项目实施中通常有业务方，产品，开发，测试等基本角色。如下图
应用软件项目组成
目前一个基本的项目实施流程是什么样的呢？大家应该都是有经验的。通常一个项目实施，从需求提出到立项，接着产品跟进丰富需求细节和最终定版，中间是开发需求分享和代码编写到提测，后续测试人员编写案例验证效果，最后用户验收。这样的瀑布式的实施流程，估计是当前最常见的软件项目实施流程。大家可能对这样的模式已经习以为常，本能的认为软件项目刚开始就是确定这样的实施模式。其实不然。因为哪怕是这个流程的提出者，好像是一个计算科学家，当年在自己的论文里第一次画出这个流程，也只是为了提出个反面案例。这从一个方面已经说明了该瀑布流模式从诞生就存在争论。我个人认为，也是出于多年实施项目的经验和体会，该模式最大的弊端就是它太完美了。它理想的认为，处于每个环节的关键角色都能完美的承担好自己的工作。它太科学，以至于无法适应解决现实中很多项目实施问题。它可能最适合存在实验室里。但是不知是万幸还是不幸，国家在新千年，提出大力发展计算软件行业的政策-国发18号文，催生了大量的软件项目，在那个时候，制定行业标准的人又以工业的眼光看待新生的计算行业，制定了很符合工业流程计算机项目评级标准-CMM认证。大量的软件外包公司也在那个时候如雨后新笋般涌出。他们当时能找到的既符合国家行业标准又能做成一些项目的流程模式，可能就只有瀑布模型了。虽然很多时候，项目都不能算是成功吧。最起码都是存在很多难解的问题的。不过，中国的软件市场也通过这个模式和标准迅速成长起来了。瀑布式流程如下
瀑布模型
对于瀑布模型的弊端，行业的有识之士肯定不会视而不见，于是就有那么一批人，在一个度假小镇一起发表了新的敏捷流程。这里我们先不细说敏捷流程的细节，但是可以大致提的是，他们认为，原先的开发模式，导致各个环节过于割裂，实施流程过长，经常会在最后部署阶段发现需求问题，导致成本上升。所以他们提出了如下模型
敏捷模型
这个模型，身为技术人员应重点强调敏捷的技术实践，即，单元测试驱动开发，重构，简单设计，结对编程，在这个技术实践的基础上再覆盖上敏捷流程的其他方面的实践。不过我们今天的主题不是敏捷的技术实践。而是领域驱动设计。软件设计无论是瀑布模型还是敏捷模型，肯定都是离不开。其实，作为开发，我们应该认识到，开发即设计。瀑布的软件开发，需要你拿到需求文档再做需求概要设计，详细设计，然后再进行编码。很多时候，你只是根据文档进行的分析和设计，可能很快过时。这不是说产品给出的文档质量不高，也不是你的需求分析不够认真，而是，静态的文档始终是静态的，它只能代表某个时间节点的需求，另外文档的二义性始终会存在，上下文的理解对于不同的人来说总是存在某些细微偏差。这样的静态的，自洽的分析支撑的最终编码成果，最后总会和需求有些出入，甚至是根本性的错误。而敏捷开发的设计强调简单设计，这里的简单设计不是不设计，而是做恰到好处的设计。这就要求很高了。要知道，大繁至简。乔布斯当年对于iphone的设计理念不就是这样嘛？但是真正能做的又有几个人呢？做简单的设计，是为了更高的弹性和使用性，支撑未来的不断迭代。那么我们该怎么实现这样的一个技术目标呢？这时，我找到了领域驱动的设计。
我认为领域驱动设计其实是给我们提供了一个新的视角和新的思维方式。这个视角不应仅开发可以具有，而是整个领域范围内各个角色都应具有。有一种说法，在软件项目中，最需要管理起的就是不断增加的复杂度。软件的复杂度其实主要不在技术上，而是在领域本身，用户活动和业务。从这个方面看，当领域的复杂度没有解决时，再好的技术设计也是无济于事。这里请大家回想自己参与过的项目，站在一个旁观者的角度重新审视下它的全部经过，可能就会对前一句话有更深的体会了。所以开始重视其技术实现的领域和领域逻辑吧，这可以是我们做出改变的第一步，最终是我们面向敏捷的第一步。
在领域建模的过程中，从开发的角度，应该和业务方，产品方，进行不断的沟通。多方应对于领域内的知识实现统一的共识和分享。这样的沟通应该持续到版本迭代完成。并在沟通中不断的积累领域的知识，以各种形式将其固定和分享出去，这样可以为团队在同一个领域的不同项目不断迭代打好地基和良好环境。因此领域驱动设计的第一步，消化领域知识。
最后还是要说，领域驱动设计不是银弹。正如《领域驱动设计》一书的前言最后所说的那样，“领域驱动设计是一项艰巨的技术挑战，但它也会带来丰厚的回报。当大多数软件项目开始僵化而成为遗留系统时，它却为你敞开了机会的大门。”这里说的机会，我想就是往更好的方向进行改变的机会吧。这也是我对于领域驱动设计最大的兴趣所在。
网友评论