经常听到领导教诲，开发的同事应该要往前走一步，去做产品？去做售前？这也是一种方式，只不过是一大步。个人觉得，在迈出这一大步之前，需要先走出一小步：从写好代码到做好设计。
下图是按照软件工程的通用做法，梳理出的标准设计指南，已经非常清晰地定义了软件设计的阶段和活动，产物规约，文档要求以及需要配合的培训。比较适合于人朋规模大、产品化程度高、外包服务模式。按照这个标准的设计指南，把每一阶段的事情做好，这是标准的开发方法论的实践指导。
有人会说，现在是移动互联网的时代，我们的产品开发要求短、频、快地上线，这种标准的设计方法已经不适合了，我觉的不完全正确。我的做法是，根据产品的愿景和市场情况，按照标准的设计指南做一些定制性的剪裁，哪怕文档全部裁完了，脑子里分析时仍然要按照这几个阶段开展对应的活动，因为这不仅是指南，更是方法论，针对这个几阶段开展过的活动，下面就梳理下我的设计经验。
首先是需求捕获和分析阶段，总是感觉需求在不断地变化，老是怪市场和产品经理，其实很多情况是我们对需求的理解不到位。既有业务理解不准确，也有支撑方式不合理。还有一点就是将原型与需求没有进行区分，原型不代表需求。将需求分析划分为业务需求与系统需求两个阶段，做好领域分析，才能根本性地适应需求的不断地变化。
接下来谈谈如何做好系统分析，在这个阶段一般又叫建领域模型，又叫概念模型，分析对象模型，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。
领域模型设计的一般步骤为：
1、从业务描述中提取名词
2、从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合；
3、从业务实体集合中抽象业务模型，建立问题域的概念
4、用UML提供的方法和图例进行领域模型设计、确定模型之间的关系。注：实体之间的关系，主要有泛化、依赖和关联，关联又分了一般关联、聚合、组合等
简言之，先分析出模型实体，然后找出模型实体之间的关系。
领域模型与实数据模型的关系：领域模型是与用户沟通的一个重要工具，是需求分析人员与用户共同理解的概念，是彼此之间交流的语言。它是一个分析模型，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。同时给我们需求分析人员和系统功能提供了一定的扩展视野，看到将来需求的可能变化或可能存在的问题。而数据模型是系统设计、实现的一部分，描述的是对用户需求在数据结构上的实现，当然数据模型中的概念模型设计与领域模型类似，缺乏的是实体之间更广泛的关系描述。
这里以开放平台业务管理为例，设计出的领域模型图纸，欢迎大家拍砖。
