我们抛开前端的实现，去理解和整理业务建模的具体内容，我梳理出这些概念：业务实体、业务事件、业务逻辑、流程阶段、交互、视图。
业务实体
实体一般用名词表示。一项业务可能包含多个业务实体，一个业务实体可以理解为一个用于表达清晰内容的对象，一般是一个由多个字段组成的对象。业务实体的作用是定义实体包含哪些字段，以及字段本身的基本元数据，这些元数据包含但不限于：该字段的类型、该字段是否是多个值、该字段是否包含字段解释说明、该字段是否有某些特殊的标记、该字段是否一定要依赖另外的字段等等。这些基础信息被定义在实体中。
业务事件
事件一般用动词表示。业务事件是在业务实体的基础上的真实业务表达。实际上，我们在讲“业务”时，往往是指一个“业务事件”，例如我所在的投融行业，“投资”“融资”就是对应的事件，在投融行业，你需要去了解一次投资/融资行为，都会发生哪些事件，这些事件是由谁，在什么时间、地点发起，持续了多久时间，过程中都必须发生哪些事情。当然，对于业务事件这个概念本身，它不包含“过程中发生了哪些事”，因为这些事处于业务事件之外，只是与它有强烈关联罢了。在建模时，我们的系统中，往往是以围绕业务事件为中心进行的，特别是在前端，因为前端涉及用户的交互，而在界面上一次性呈现的，往往是这一业务事件的全部，而几乎不会以某个业务实体为单位进行独立呈现。这也就意味着，在前端，实际比在后端要进行更复杂的串联思考。
事件边界
如上所述，一个业务事件往往囊括多个业务实体，比如一次投资行为，要囊括投资方、被投方、投资团队（业务人员）、基金方（如果存在SPV），同时要囊括该次投资的交易信息、各类合同文件等等，而其中的每一个实体，往往右内涵自己更细的实体描述，例如被投方要包含被投的公司/主体、其管理层人员、上市信息、已有的投资人等等信息。不过，我们仍然要为一次投资事件划定边界，该事件包含了上述实体，但这一关系也可能仅仅是引用关系，而不是从属关系；另一方面，该事件还会有自己的流程，我们都知道投资流程非常复杂，设计的钱、人、机构都很多，但是，这些信息往往并不是该次投资的本体信息，它们是附带出来的，我们可以在项目里面加一个流程的引用，也可以在流程里加一个项目的引用，都是可以的，因此，这两者就有比较明确的边界，我们建模的时候不需要把流程的问题考虑在该事件内。
总而言之，“业务事件”虽然用动词表示，但是往往具有名词意义。比如，我现在要“做一次投资”，这里的“投资”本身虽然是动词，但在“做一次”的动词前提下，它就是名词。而名词的建模往往具备通用的方法论。
业务逻辑
业务逻辑本质上是业务规则，所谓规则，就是一条一条的前提与指令集合，这在本栏目的其他文章中有解释。所谓“前提与指令”，就是“当A的时候，应该B“，A是前提，B是指令。而指令在前端是非常难以固定化的，因为在前端，指令除了变更数据、状态，往往还要求UI层面作出响应，而后端在这一点上就轻松很多，常常只需要变更数据或状态即可。因此，在前端，这一部分不得不分开，虽然它们原本应该耦合在一起，但是从前端的特性出发，我们必须把它们原子化拆分，其中“前提”往往被集中管理，而“指令”则被分散，有的不设计UI层面，只涉及数据和状态，就可以和“前提”并且放置，而涉及UI层面的，只能在视图层中管理。而真正要执行该逻辑时，我们必须从多个地方取出“前提”和“指令”，然后进行运行。
另外，“前提”和“前提”之间往往还有一定的先后、嵌套顺序，但是常常“指令”又仅对单一“前提”进行响应，这也就意味着在管理上其实需要非常小心，即使做了非常强的封装，也必须考虑分散管理和集中使用之间的冲突所带来的不确定性。而大部分前端系统出现业务层面的bug，都是因为这个管理和使用的不当造成的。
我们要探索一种合理且高效的业务逻辑管理模式，在这种模式下，前提和前提之间的顺序关系可以很好维护，与此同时，前提和指令具有绑定关系，有这样的机制的话，当逻辑开始运行，它们就必须按照特定的顺序，以及在特定的节点上执行特定指令，如此运行，这一就可以避免很多问题。
流程阶段
流程往往是针对事件的，可以说它是事件的衍生品，当一个业务（事件）发生时，如果它没有特殊的需要，就不需要流程，它仅仅成为一个事件的记录。但是，如果这一业务需要不同层面的人在不同的情况下参与进来，最为常见的参与方式就是审批，当然还有补充信息、修订错误、线下处理某些事情后记录到线上等等。流程分阶段，人员在这个事件中的出场和离场也可能随着阶段的迁跃而发生。同时，非常重要的一点是，事件中所包含的实体的字段，在不同阶段可能会附加对应的业务逻辑。例如，在阶段1时字段a不需要填写，但是到了阶段2就必须填写。
狭义的流程往往只发生在事件出现之后，但是广义的流程从事件出现之前就开始了。比如我们现在准备开始投资一家公司了，那么我们其实在开始之前就已经做了非常多准备工作，例如收集该公司的各种信息，与该公司的一些高层进行了接触等等。但是这些准备阶段的工作记录，常常因为我们不确定是不是准备作出投资计划，而不知道把这些信息放在哪里，也就是“在事件开始之前”，这些信息已经有了，但是因为“事件还没有开始”，所以，这些信息放在哪里呢？不管放在哪里，一旦我们准备开始投资这家公司，在系统中去创建这次投资事件时，这些信息就会马上拉取出来，作为该事件的一些信息。也就是说，对于投资事件的流程而言，在事件开始之前就已经存在了，只是它是概念上的，而非真正存在。
基于“广义流程”的理解，我们的事件业务逻辑的管理，就可以被关联到流程的阶段上，因为这个事件从还未开始到事件结束，都处在流程中，而大部分逻辑都可以被确定在某个流程阶段。（当然，有些逻辑是很底层的，应该直接在实体或事件模型中写死，例如某一个字段具有特定的业务性质，它的值一定是另外两个字段计算而来，这种逻辑就不属于流程上的逻辑，而是底层逻辑。）
交互
交互是真正意义上的“动词”，所有的文档中有关交互的描述都是“要干什么”“应该怎样”“必须如何”，例如“字段A大于10时，弹出提示语xxxx“，其中”弹出提示语“就是一个交互行为。而这一整段话就是一个业务逻辑，但是注意，它是一个“业务的交互逻辑”，因为它是基于业务的某个前提，执行交互的某个指令。
在前端，处理交互其实是很麻烦的，因为它一半具有视图层面的意义，一半具有非视图层面（操作数据）的意义。因此，我们要想办法把交互从中解放出来。我们需要建立交互模型，它一半提供给视图层，让视图去调用它，作为视图层的响应，另一半它要读取和操作数据，使得业务发生演进。
另外，下面我们会讲到，视图本质上是抽象的状态的具体表现，在交互模型中，我们可以提前定义好作为视图抽象的状态，并且在面对某个与视图有关的交互指令时，操作其状态，从而达到与视图层完全没关系的效果。
视图
视图是前端最熟悉的部分，也是业务系统最无关紧要的部分，因为对于非常多的业务系统而言，其核心价值在于数据，即使没有前端的界面，只要你有手段让我准确获得数据，我也是可以接受的。当然，如果没有前端的界面，数据的创建、补充、修订，审批的进行，文件的上传，都是非常麻烦的，所以，不能因为它对于业务无关紧要就直接否定它的存在。
视图的本质是抽象的状态的具体表现，也就是著名的公式ui=f(state)，在业务系统中，我们需要对业务数据状态化，使“业务的数据+界面的状态”成为一个大状态，交给视图，视图拿到这个大状态之后，按照不同端的特征进行渲染，提供人机交互的入口，调用交互模型的方法，响应新的大状态的变更。
在很多情况下，视图具有相似性，对视图进行建模，可以有效的解决此类复用问题，例如在PC上有一个罗列字段的列表，在APP上也有一个同样的列表，只不过它们的长相不同，但是它们都是一个列表，有label和value两个部分，value部分还需要进行一些格式化处理，以及一些操作上的按钮。这些相同的部分，我们可以在模型（用抽象类更好）中撰写，再在两端各自实现界面的呈现。
