模型描述的关系模式_产品经理的一些图—架构图、流程图、用例图、领域模型...

记录一些产品研发过程中经常用到的图形，包括以下内容：

• 架构图
• 流程图
• 用例图
• 领域模型
• 线框图

1、架构图

架构图是一个产品经理对整个产品，服务&商业模式有一个高阶抽象理解后的可视化的表达方式，同时也是产品研发初期最应该去规划设计的东西。

• 为什么要画：梳理自己对产品方向的判断；让他人可视化的理解你的产品架构
• 何时需要画：在复杂项目开始前写：当你要开始设计一个系统性、完整的需求时
• 如何画： 搞清楚要画的架构图的类型；确认要元素（技术、产品、服务）；简单架构的关联关系：包含、支撑、同级并列……；复杂架构的关联关系：引用合适的架构和模型，分层后在逐层按照简单架构的关联关系处理；输出逻辑结构，关联关系清晰的架构图。主要包括下面3类架构图：

1、技术&功能的产品架构图：相对简单的产品功能架构图，列出产品已经拥有或初期产品规划阶段，应该拥有的功能进行抽象归类，描述出模块结构和关联关系。

2、基于产品，技术和功能的服务架构图： 模型和框架又是一项很重要的能力，工作中我们要去积累遇到的一些框架和模型，理解后有利于参与架构图的设计，也有利于锻炼我们的抽象思维，架构的概念更多的被软件工程所引用。

• 计算机系统的：输入-计算-输出 模型；
• MVC框架的：模型(model)－视图(view)－控制器(controller) 模型；
• 互联网的七层协议模型： 7 应用层、6 表示层 、5 会话层、 4 传输层 、3 网络层 、2 数据链路层 、1 物理层 ；
• 软件系统架构的分层模型：第一层数据存储层， 第二层数据交换层，第三层应用支撑层，第四层应用层，第五层展现层，第六层用户层，等。

3、基于功能，技术，产品与服务的系生态&商业模式架构图：功能基于技术，产品基于功能，服务基于产品，生态系统和商业模式基于所有。

2、流程图

指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程，流程是自然而然就存在的。但是它可以不规范，可以不固定，可以充满问题。所以就会造成看似没有流程。

• 为什么要画：流程图可以提供一种简单扼要的“缩略俯瞰图”，帮助观众快速了解业务如何运转。
• 何时需要画：业务梳理时，只要有事情和任务，流程就会有，但是并不是所有的流程都适合用流程图的方式去表现，适合用流程图去表现的流程是一定程度固定的有规律可循的，流程中的关键环节不会朝令夕改的。
• 如何画： “业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。这样一个层次关系符合人们的思维习惯，有利于企业业务模型的建立 企业部门之间的层次关系表。一般来说，我们可以先建立主要业务流程的总体运行过程（其中包括了整个企业的大的战略），然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。”

复杂业务流程图

简单流程图（分解后）

3、用例图

用例( Use Case )是一种描述产品需求的方法，使用用例的方法来描述产品需求的过程就是用例模型，用例模型是由用例图和每一个用例的详细描述文档所组成的。在技术和产品的工作领域里都有用例模型的技能知识。

• 为什么要画：技术人员的用例主要是为了方便在多名技术人员协同工作，或者技术人员任务交接时，让参与者更好的理解代码的逻辑结构。产品人员的用例主要是为了方便技术研发和功能测试时，让参与者更好的理解功能的逻辑。
• 何时需要画：在复杂项目开始前，梳理产品需求范围的时候，用例图在总体上大致描述了产品所能提供的各种服务，让我们对于产品的功能有一个总体的认识。
• 如何画： 用例图并不是画成了图形的用例。用例图包含一组用例，每一个用例用椭圆表示，放置在矩形框中；矩形框表示整个系统。矩形框外画如图所示的小人，表示参与者。参与者不一定是人，可以是其它产品、软件或硬件等等。某一参与者与某一用例用线连起来，表示该参与者和该用例有交互。除此之外，完成用例图后，我们还需要描述每一个用例的详细信息，才能完成产品的需求。用例图，如下所示：

4、领域模型

领域模型，它是以面向对象的视角看待现实世界的结果，也就是通过类图来描述现实世界中各种事物之间的关系。领域，指的特定行业或者场景下的业务逻辑，DDD 中的模型是指反应 IT 系统的业务逻辑和状态的对象，是从具体业务（领域）中提取出来的，因此又叫做领域模型。

• 为什么要画：当我们建立了领域模型后，我可以考虑使用领域模型指导开发工作，包括：指导数据库设计；指导模块分包和代码设计；指导 RESTful API 设计；指导事务策略；指导权限指导微服务划分（有必要的情况）。

• 何时需要画：当梳理完业务需求，对业务进行充分的抽象，找出这些隐藏的模型，并搬到系统中来。如果建立一个餐厅管理系统，那么发生在餐厅的所有事物，都要能在系统中找到对应的对象，那么这个系统的业务逻辑就非常完备。
• 如何画： 基于我们梳理的用例，按照以下步骤绘制领域模型

A. 发现类和对象：尽可能多的找出概念类（识别方法：概念类分类列表、名词性短语）

• a.概念分类列表：对用例进行识别：实体、过程中的信息、角色的输入输出、操作设备等（人、事物、地点、组织、概念、事件、规则、抽象名词、交易项目、角色、设备、组织结构）。
• b.名词分析法：识别问题域和用例描述中的名词和名词性短语作为候选的概念类和属性，从候选项中，摒弃多余的名词，确定最终的对象（注意是作为类还是属性，类可以是一种标识、状态和行为）

例如：通过业务分析得到的一个非常基本的领域模型。在点餐系统中，会有座位、订单、菜品、评价 几个模型。一个座位可以由多个订单，每个订单可以有多个菜品和评价。

B. 建立类之间的关联（关联、继承、依赖）

• 关联：类之间的某种语义关系
• 继承：一般到特殊
• 依赖：表明一个元素（源元素）的定义或实现依赖另一个元素（被依赖元素）的定义或实现

例如：还是餐厅买菜为例，

• 大嘴说去买菜，这里的菜被抽象出来应该是食材采购品，如果掌柜对这个菜进行管理，应该具有采购者、名称、采购商家、采购价等。
• 秀才说实习生把账单中的菜算错了价格，秀才需要对账单进行管理，这里的菜应该指的账单科目，现实中一般是会计科目。
• 老白说的客人点了一个酱鸭，这里老白关注的是订单下面的订单项，订单项包含的属性有价格、数量、小计、折扣等信息。

C. 添加类的重要属性（类的语义完整性、类的作用、问题域相关特性等）

• a.语法：可见性 属性名：类型 多重性=默认值{特性表} / [可见性] 属性名 [：类型] [=初始值]
• b.属性类型是简单的数据类型为佳，如果是复杂概念，考虑是否单独作为一个概念类
• c.任何属性都不表示外键，即不应该用属性来联系概念类，区别于数据库设计中的外键

按照以上步骤就能划出领域模型了。

注：属性可以另外写。

线框图

-待更新