产品设计进阶思维：怎样进行业务的抽象建模
抽象建模是产品设计中的一个很重要思路，它能帮助我们将一些看似没有任何规律的业务进行一个标准化。
我们需要不断地对复杂业务进行抽象建模，从而让复杂非理性的事物（需求）变得有非常明确的规则，各个业务之间有清晰的划分。
抽象建模的本质是什么？这里我可以用一句话来进行概括：业务组件提取。
所谓业务组件提取，就是指我们在进行业务分析过程中，不断将业务划分成若干个小的组件与模块。例如我们可以将电商系统划分为商品中心、订单、支付、物流、会员这五大组件，通过这五大组件共组建起了一个完整的电商系统。其实，业务建模的过程，就是产品开发的核心过程。
在我们的工作中,需求的具体实现逻辑往往是不明确的,一般都是老板或者产品甩过来一个页面或者要求,剩下的就要靠我们自己去思考了,而建立业务模型,往往就是开发中最难也是最烧脑的一步.很多人可能想许久都不知道一个业务该怎么实现,或者是先想清楚了,但做着做着就发现之前的逻辑是错的,又只好重新改.
可以从以下两个方面入手可以快速把握新项目的过程。
业务方面：
1。询问该项目产品业务关键点，以及业务大致流程，做到胸中有图（业务流程图，架构图）
技术方面： 任何业务有个性同时也有共性，那么我们可以从业务共性入手来降低理解业务的难度。
1。模型（跟业务紧密联系的对象，如：订单，用户，账户对象等）从模型入手了解业务核心参与者，在模型中应该搜索聚合跟对象（比如，用户，顺着用户找下去，就可以发现与用户关联的对象，从也就明白了用户与之关联的对象间的关系）
2。规则（规则其实也是一个模型，但这个模式系统全局的，是其他模型的执行标准，比如用户购买商品，如何收取佣金，那么这个应该是个规则了，在系统中一 般表现为配置，但也可以是一个核心算法）
3。场景上下文（时间阶段，事件性质，如：转账，下单，比如 我做一个监控系统，那么分布式服务端（NoSQL）监控是一个场景，监控用户访问轨迹又是一个场 景，不同的场景就觉得了使用什么样的规则，场景中一个重要元素是时间，如8~20点是用户访问高峰阶段，一个月月底应该分库了就是场景，场景是使用规则 的潜规则，即场景觉得规则的使用。）
4。事件（简单说事件是一个具体的动作，即做什么。元素：事件的发起者，事件执行环境，事件的协作者，如用户转账，用户就是事件发起者，那么转账需要什么呢？账户，账户就是参与者）
5。状态（状态可以说在业务某些过程中能够决定是否继续执行事件的决定性因素，如果用户购买商品时，商品不足，那么商品不足其实是状态，这个状态不能满 足要求那用户购买商品这个行为（事件）应该终止的事件阶段性结果，事件完成时的结果，事件结果保存到媒介，如：SQL，NOSQL）。
业务模型是对现实世界的抽象，而不是对现实世界的枚举。
抽象得好的业务模型是简洁清晰的，一看就明白的。而枚举出来的数据模型是复杂，晦涩难懂的。
如果一个模型很复杂，多半是对大量业务场景的枚举，而不是抽象。
实际应用中，抽象模型的每一部分都会得到应用，而在枚举的业务模型中，你会发现很多内容只在很少的应用场景下才会使用，甚至在软件的整个生命周期中都没有得到应用。
