轻松学DDD之一：模型驱动设计

　　我是2012年开始接触到DDD（领域驱动设计）的， 后续陆陆续续研读过几遍Eric的大作《领域驱动设计：软件核心复杂性应对之道》，也使用DDD重构过一个项目。总的感受是DDD的一些概念比较晦涩难懂，很难掌握，因此想写个系列短文，希望能用通俗易懂的语言帮助大家更轻松更深入地理解DDD。文章很多都是我个人体会和理解，难免有错误，希望大家能及时指正，共同提高。
　　本文是系列短文第一篇，介绍ＤＤＤ的起始概念模型驱动设计。　　软件开发可以看做是一个把用户需求转换为可正确运行的程序的过程，其中最关键部分是把用户需求转换成代码。我们要学习的DDD实际上就是一种软件开发方法，它相比之前的软件开发方法，能更好地应对软件的核心复杂度。为了能更好的理解它，我们先回顾下之前的软件开发方法及其存在问题。
　　在上世纪６０年代，由于需求简单，软件开发以作坊式开发为主。但是随着硬件的飞速发展，软件复杂度也迅速激增，终于在７０年引发了软件危机。为了应对危机，业界借鉴成熟生产制造管理方法，发展出以“过程为中心”的瀑布式开发方法。　　瀑布式开发把整个软件开发过程划分为需求分析、方案设计、编码、测试等阶段，希望以这种类似工业流水线的作业分工方式来控制软件开发的风险和成本。　　为了解决瀑布式开发的开发效率低下、响应需求速度慢的问题，轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速流行起来，极限编程就是其中的一种。
　　XP主要由13个实践构成，是一种近螺旋式的开发方法。它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
　　为了与瀑布式开发做对比，我们把ＸＰ简单理解为下图：

　　通过上图我们可以看到，XP没有划分分析、设计、编码和测试等阶段，需求可以在一个周期为1~2开发云主机域名周的迭代中快速交付。XP之所以能做到快速交付，有如下几个原因：　　XP非常反对做预先设计，需求分析与设计会被拆分到用户故事乃至TDD的小步迭代中去做，在每个小迭代中代码只会根据当前需求简单实现；当在后续迭代过程中发现代码难以满足新需求时，需要通过重构来增加代码对新需求的适应性，以便能够快速实现新需求。这种做法固然能带来很多好处，但是也存在一些缺陷：
　　为了弥补XP在应对软件核心复杂度的缺陷，eric在2003年提出了一种新的方法，他认为我们需要引入领域模型并围绕它来做需求分析和软件设计，这就是模型驱动开发。这一论述有以下几个要点：　　最后总结下，模型驱动设计通过对软件核心复杂度的统一建模，解决了瀑布式开发在需求分析、软件设计上的沟通、反馈和知识整合上的缺陷，也解决了XP极简主义设计存在的缺陷。
　　文本重点叙述了我们为什么需要领域模型，领域模型构建需要注意的几个基本原则，但是具体要怎么来构建领域模型呢？请看下一篇《轻松学DD之二：如何高效消化知识》。

相关推荐: jmeter环境变量配置

效果图：环境配置：编辑：vi ~开发云主机域名/.bash_profile#jmeter:路径JMETER_HOME=/root/tools/apache-jmeter-3.3PATH=$PATH:$HOME/bin:$JMETER_HOME/bin:expo…