产品举例：如果我们要做一个芒果TV后台管理系统，简单的方式和复杂的方式分别怎么来做呢？
一、简单系统设计方式——需求驱动设计
针对简单的后台产品，我们通常采用需求驱动设计（Request-driven design，以下简称RDD）。
1、概念
所谓需求驱动设计，是指我们在设计后台时，根据上级、运营、市场、客服、前端产品等需求方所提的具体需求，直接进行产品架构、功能设计。这种设计方式简单快捷，与我们做前端产品思路、方式相同，对于很多做前端产品的同学而言，这种方式是最容易理解和掌握。
2、设计流程
3、流程拆解
（1）明确目标
任何一个产品的萌芽，往往是因为一句话，一个问题，或领导的一个idea，而这些起因，就是我们的产品目标，这些目标有时很模糊，但对于系统产品，这个目标都是很明确的，明确的业务场景下，XX用户产生的明确需求。例如我们要做芒果TV，分别有APP、web、PC、TV四个端，就需要有一个统一的管理后台，对前端进行支撑，运营人员能够对内容进行维护。
（2）需求分析
明确了方向，接下来就需要做需求调研。
第一步：穷举用户角色
进行需求调研时，需要先找用户角色，再找需求。
清晰地列出使用此系统的用户角色，以用户角色为划分维度进行调研。因为后台产品不同于前端，不同的用户角色需求差异很大，甚至风马牛不相及，而每种角色对应的用户都是这个系统的目标用户，并不存在所谓的核心用户和潜在用户一说，这些用户都是重要的，都需要满足他们的需求。例如，使用芒果TV后台管理系统角色包括运营、产品经理、公司管理者、审核员。
第二步：需求调研
调研方式——深度访谈
与前端产品不同，后台产品的用户在现实生活中离我们很近，很容易就能接触到，这个时候就不要用调查问卷这种大覆盖面的方式了，一是用户基数没有那么大，二是后台需求基本不需要做定量分析，无需通过这种方式去挖掘需求。所以直接与用户交流、访谈是最快速有效的方式；
调研对象——关键人
我们的访谈对象，需要尽可能满足资深、直接使用、有话语权三个条件，因为这种关键人所提出的需求会更加全面、具体且有深度，能够清楚的解释为什么要有这个功能，如果没有会出现什么后果，还能巴拉巴拉一堆历史故事，这种用户就是完美的访谈对象。这些被伤害过的人，知道心痛的滋味；
第三步：建立需求池
根据访谈内容，建立需求池。例如，在对运营、产品经理、公司管理者、审核员访谈后，建立了以下表格
（3）结构设计
将调研后的需求进行初步筛选过滤后，需要根据确定、高优先级的需求，归纳这一期后台所需实现的功能模块。
做功能模块划分，需要秉持一个重要原则：一个角色，一个模块，完成一件事。也就是一个具体的角色，能够在一个功能模块中完成他想完成的任务。原因主要是以下两点：
降低用户记忆成本，提升操作体验。你绝对不想为了做一件事，要在多个模块跳转、多个页面点击吧，这个看起来对前端产品再正常不过的要求，后台经常没有达到；
便于权限区分。做系统产品，权限划分永远是重点关心的，将一个角色要进行的操作单独作为一个模块或模块下的子栏目，方便做权限设置；
同样，划分模块后进行栏目划分，然后按照操作流程，从上至下排列，就能得到以下产品结构图：
至此，简单系统的产品需求设计阶段就告一段落了，后续步骤，且看下回分解。但既然说这种方式只适用于Easy模式，那一定是有原因的。
4、不足
这种设计方式，用开发的行话说，是一种面向过程的设计方式。这种方式有一个专有名词——贫血模型。
贫血模型有以下几大致命缺点：
创建的对象不准确，直接影响产品和开发对业务的正确把握和扩展；
业务逻辑分散，业务难以复用；
业务间耦合度高，迭代及维护成本极高；
名词定义不一致，开发与业务出现沟通问题。
二、复杂系统设计方式——领域驱动设计
为了解决上述问题，同时应对复杂的系统产品，就需采用领域驱动设计（Domain-driven design，以下简称DDD）模式。
1、概念
领域驱动设计，是指在一个具体的领域中，一种面向对象的设计方式。例如，我们要做一个更大的芒果TV后台管理系统，以满足更多角色的更多需求，那么这个系统就属于一个具体的领域——视频娱乐领域。在这个领域中，包含影片、演员、订单等对象，这些对象就是我们要面向的设计目标，而非直接根据需求做设计。
2、流程
3、流程拆解
在这种方式的流程中，增加了“建立领域模型”和“系统划分”两个环节，其他环节与RDD相同，就不再赘述，现针对新增的两个环节做说明。
（1）建立领域模型
此处的领域模型，是一种简化后的E-R图。E-R图是后台开发在数据库设计中通常会用到的一种模型，用来表示实际业务中各个实体及其关联关系，核心三要素是实体、联系、属性。如下图中，长方形体现的就是实体，也就是实际业务中的各个概念；椭圆形体现的是实体包含的属性，类似概念下的各个字段，菱形体现的是实体间的关系。
当在需求设计阶段时，并不需要像做数据库设计那么复杂的模型，我们需要创建的领域模型，就是要根据实际业务，展现全部的实体及其关联关系，无需属性，避免在规划阶段陷入过深的细节。
第一步：与领域专家一起，梳理实体
领域专家，是指对这个领域非常熟悉的人，可以是业务人员、老板、产品经理等任何角色。这个专家对领域内的各种业务场景和各种业务规则非常清楚，有能力表达出系统该做成什么样子，有哪些核心业务关注点。
在本文的例子中，我们梳理的实体包括用户、影片、栏目、推荐位、演员、导演、订单、运营活动等，在这些实体概念里，就是一个个的具体对象，例如演员里有刘亦菲、刘德华。每个实体要求能用文字精确的、没有歧义的描述其涵义以及包含的主要信息，同时每个实体定义要完全独立，概念上不能有交叉或模糊的界线。
第二步：梳理关联关系
确定了实体，就需要建立实体的联系，标识实体间的对应关系。
实体联系：
直接关联：实体间直接关联，在系统中需手动建立联系的实体；
间接关联：根据实体图，能够通过间接关系找到唯一对应实体。通过间接关联关系，往往可以通过多条路径找到同一具体实体，如果出现不同路径找到不同目标，那就需要重新检查关联关系是否正确；
对应关系：
1对1（1:1）：1对1关系是指对于实体A与实体B，A中对象至多与B中一个对象有关系；反之，在实体B中的每个对象至多与实体A中一个对象有关系；
1对多（1:N）：1对多关系是指实体A与实体B中至少有N(N>0)个对象有关系；并且实体B中每一个对象至多与实体A中一个对象有关系；
多对多（M:N）：多对多关系是指实体A中的每一个对象与实体B中至少有M(M>0)个对象有关系，并且实体B中的每一个对象与实体A中的至少N（N>0）个对象有关系。
关联建立原则：
关联尽量少。实体间的复杂的关联容易形成实体关系网，这样对于我们理解和维护单个实体很不利，同时也很难划分实体与实体之间的边界；
化繁为简。在建立关联时，需要挖掘关联关系的限制条件，如果存在，那么最好把这个限制条件加到这个关联上，往往这样的限制条件能将关联化繁为简，即可以将多对多简化为1对多，或将1对多简化为1对1；
第三步：走查场景，修改领域模型
关联关系、对应关系是否正确？
分析关联，通过对业务的更深入分析，明确关联的方向或者去掉一些不需要的关联；
这些实体及关联关系能否全部覆盖这些业务场景？
（2）系统划分
为了解决在方法一中遇到的问题，需要采用微服务的思想，根据实体间的联系强弱，以实体为对象，划分到不同系统中。
将每个系统独立开（解耦），系统与系统间通过接口调用数据，公共模块单独作为一个系统（如此处用户管理系统），每个系统都有各自的三层结构（详见上篇）。
三、两种设计方式总结
介绍完两种不同的需求设计方式，再来看这两种方式的联系。
1、如何选取
这个图表示随着系统复杂程度增加，两种设计方式开发时间的变化趋势。可以看出，但产品复杂度低时，RDD的模式会很快捷，这个就非常适合初创型、小型的系统设计，当产品复杂到一定程度时，RDD的开发时间会指数上升，而DDD的模式则始终比较平稳，所以DDD会适合复杂的系统设计。
2、两种方式中的实体
上篇说到，后台三层结构中，业务层也叫领域层，其实和领域模型中的领域是一样的。RDD在数据库设计时依然需要有E-R图和实体，但产品经理做需求设计时可以不用考虑（当然有资源这样做更好），因为对于简单的后台产品而言，无需在初期理解的那么复杂，同时对很多从前端做到后台的产品而言，不用学习领域模型相关的内容。
那么在DDD中，对于一个已经对业务非常熟悉的产品经理，可以直接跳过实体，进行系统的微服务设计。但需要注意一个实体在多个系统都存在的情况，这个时候就会导致同一实体的数据，存储在多个系统中，无论是数据管理还是调用，都会存在问题。所以老司机们还是要划分清实体，只是不用那么细致。
3、两者关系
写到这里，大家其实就会发现，这两种方式其实是一种包含关系。对于复杂系统而言，需要先采用DDD模式进行前期需求设计及系统划分，当微服务化后，每个子系统也就变成了简单系统，也就可以采用RDD的模式了。
网友评论