我正在参与「启航方案」

在对事务价值、事务用例和流程进行剖析之后，接下来就要对事务进行详细剖析。咱们知道，程序自身便是一个状况机。那现在咱们用程序来描绘一个需求，也便是要用一个状况机来描绘需求，那天然地，事务需求也是一个状况机。所以，剖析需求，其实便是在剖析怎样用状况机表示这个需求。而在事务需求中，往往用事务目标来表示事务需求的状况。所以，在详细剖析这一步中，咱们要做的只有两步，辨认事务实体目标，剖析事务实体目标。

辨认事务实体目标

怎样从事务需求中辨认出事务实体目标

• 动词名词法：一般来说，咱们在评论需求的时分，总能描绘出一些需求场景，比方，用户A预定了一个会议；用户A进入了视频会议；等等，这个时分，咱们就能清楚明了地得到一些事务实体目标和这些目标的行为：视频会议是事务实体目标，用户能够参加视频会议，意味着视频会议这个目标需求供给参加的行为
• 用户流程剖析法：通过主流程剖析得到的事务流程，咱们能够看到用户在运用咱们的产品时，要通过哪些流程，这些流程中，应该会对应着一个或多个事务目标，那么在这些 事务流程中，运用动词名词法描绘用户的运用场景，即可提炼出对应的事务实体目标。

怎样判断找到的是一个事务实体目标

事务实体目标是和DDD中的实体目标是对应的，有几个显着的特征：

• 实体目标有仅有id进行标识，且id一般都能够区分为事务id和主键id，在需求剖析中找到的是事务id。事务id的特点，便是具有事务意义的，用户能了解到这个id的意义的。比方，咱们在规划数据库时，一个视频会议，会用一个数据库主键id来进行标识，这个数据库主键是无事务意义的，用户不能了解的，可是视频会议的会议号是具有事务意义的，用户知道这个会议号的背后有且只有一个视频会议。而咱们在这一步的意图便是要找到会议号这个仅有标识视频会议的事务id，天然也就得到视频会议这个事务实体目标了
• 存在生命周期。一个事务实体目标，都会阅历 创立，运用，毁掉 这几个生命周期，而且或许会依据事务需求会再衍生出其他的生命周期。所以，判断找到的目标是不是事务实体目标，能够看它是否具备生命周期。

综上，咱们能够简略地归纳出以下内容：

剖析事务实体目标

辨认出事务目标后，咱们接下来遇到的问题便是，要剖析事务实体目标的什么内容？ 总的来说，需求对事务目标剖析以下内容：

剖析目标的生命周期

目标的生命周期要从实际需求动身，从需求剖析的过程中，咱们剖析出了事务流程，那么对应地，咱们需求从事务流程中提炼出目标的生命周期。

比方，视频会议中会有录制的功用，那么咱们能够提炼出Record这个实体目标。对应地，录制在视频会议中存在两种状况，录制未开端和录制已开端，其对应的行为便是开端录制和结束录制。所以录制这个实体目标，对应的生命周期能够如图所示：

剖析目标的行为

• 对称的行为：行为应该是对称的，假如呈现不对称的操作，应该阐明详细的原因。

比方，静音必定会伴随着撤销静音，这个行为是对称的；可是整体静音，并不一定会伴随着撤销整体静音，由于在视频会议中同时让大家都开麦的场景几乎不或许存在，那么完成撤销整体静音这个功用的优先级就没那么高，能够先不做。所以这个时分的行为能够是不对称的。

又比方， 以录制这个目标为例，存在开端录制的操作，必定会存在结束录制的操作。

• 重复的行为： 在同一状况下重复履行同样的行为，应该怎样处理。

比方，A现在现已处于静音状况了，接着同一主持人，或不同主持人又对A履行了多次静音操作，那当呈现这样的情况时，对主持人和A来说，应该怎样体现呢？

又比方，关于开端录制这一行为而言，在录制已开端的状况下，再次履行开端录制，该怎样处理呢？这时分就会发掘出开端录制这一行为需求满意幂等性了。

• 冲突的行为：是指对同一状况值履行不同的行为，导致产生不同成果时，该怎样处理。

比方，A、B是主持人，C是一般参会人，此刻A申请开启C的麦克风，而B要进行整体静音，那么关于C来说，两个行为都有效，且这两个行为冲突了，那这个时分该怎样处理呢？

• 并发的行为：同一时刻运用创立同一资源时，存在并发操作的场景，此刻应该怎样处理。

比方，假如视频会议被规划成有人参加则创立，没人参加则不创立，那么当A和B同时运用同一个会议号参加会议时，就会存在并发操作，此刻视频会议必定不能创立多个，否则就会违背了一个会议号同一时刻只能有一场视频会议的规矩。关于这个场景，就需求运用分布式锁等措施来对并发操作进行处理。

又比方，视频会议中有A、B两个主持人，他们同时开端录制，那么此刻咱们的预期是同一时刻一场视频会议只能存在一场录制。那开端录制的行为需求满意仅有性的约束。

剖析目标之间的联系

目标的联系首要剖析数量联系和依靠联系。其间，依靠联系尤为重要。

• 数量联系。数量联系比较简单辨认，一般分为三种，1对1（1: 1）、一对多 (1:n)、多对多 (m: n)。辨认目标之间的数量联系，有助于咱们对数据库进行规划，通过目标能够映射到数据库表中，目标与目标之间要怎样相关。

• 依靠联系。若两个目标之间存在依靠联系，意味着一个目标的创立需求依靠另一个目标存在，一个目标的毁掉也或许影响到另一个目标，那么在剖析时就要同时重视两个目标之间要怎样配合。

  比方，咱们剖析出来视频会议和视频会议成员两种目标，那么视频会议成员有必要在视频会议创立之后才会被创立出来，而在视频会议结束的时分，视频会议成员也有必要跟着毁掉。这涉及数据一致性的问题，理清这其间的依靠联系能够让咱们知道目标之间应该怎样坚持数据一致性。

剖析目标中的特点（状况值）

目标的特点，其实都是状况值。依据特点是否可变，分为两种，不可变特点和可变特点。

• 假如特点自目标诞生，直到目标消亡，都不会改动，这种叫不可变特点，比方目标id、创立时刻、事务上的仅有标识（如身份证等）。这种不可变特点的要辨认出来比较简略，而且由于其在目标生命周期不会改动，因此对事务流程的影响不大。
• 假如特点自目标诞生之后能够改动，则称为可变特点。对这种特点进行剖析会比较费事，由于特点的改动往往带来一系列的改动，概况能够参照下面的状况值剖析。

事务实体目标状况值剖析

在事务需求开发中，目标的状况往往需求记录到数据库，或许其他的存储介质中。关于状况值的处理假如不妥，会产生相当多的bug和技能债，更严重的乃至会导致用户数据丢失，引起丢单。因此，事务实体目标的状况值剖析，是整个规划重中之重，值得多花一点时刻来仔细整理。

辨认目标的状况

做过事务需求剖析的同学都知道，要找齐目标状况并不简单，而且都会有如下几个问题：

• 什么是状况？

依据需求、交互和整理出来的主流程，辨认出哪些内容需求记录。所有用户设置的选项、客户端显示出来的值等等都是状况。注意，咱们只需求将精力花在可变特点上即可，关于不可变特点，由于对事务的影响不大，在精力分配上能够不用过多重视。不过条件是你现已承认这个特点是不可变的。

• 还没进行体系规划，在完成时需求的状况值没找出来怎样办？

不需求找出体系规划时的状况值，那是体系规划要关怀的工作，咱们只需求找到需求中说到的状况即可

• 需求剖析上说到的状况仍是找不全怎样办？

不需求担心，清楚明了的状况必定能找到，其他没那么显着的状况，咱们能够通过后续的几种技巧把它们找出来

• 假如发现有些状况没有依附在目标上怎样办？

这是不或许的，假如真的有这样的状况，那必定是缺少了对事务实体目标的笼统，阐明这儿需求提炼出一个事务实体目标。

剖析目标的状况

关于找到的状况值，逐个剖析清楚：

• 初始状况值是什么
• 状况产生改动的断定条件：
  • 谁能改动状况值（只有主持人才能静音他人）
  • 在什么情况下不能改动状况值（主持人不能被静音、视频会议开端了不能修正等）
• 状况能够怎样改动
  • 改动状况有几种进口？（预定概况页能修正，视频会议界面中也能修正）
  • 状况值怎样产生搬运？（假设一共有A、B、C三种状况，只能从A -> B -> C这样搬运，现在是A状况，在通过什么操作之后会变成B状况，什么情况下不能从C状况变成B状况）
  • 状况值能够是什么？
    • 是否破坏了事务仅有性：状况产生改变后是否破坏了事务上的约束条件（比方 视频会议要求会议号仅有，假如支持人为修正会议号的话，修正后的会议号不能和已有的会议号重复，否则就会破坏了事务上要求会议号仅有的约束）
    • 状况的鸿沟值是什么：对状况的取值测验拓宽它的极限，看它的极限值在什么地方。不止是产品司理，乃至是研制往往都会在这个地方缺少考虑
      • 数值型的最大最小值
      • 字符串型的长度限制
      • 字符串型的内容限制：假如是文本内容，输入一些违规词汇能否正确处理？假如是url、邮箱等有固定格式的内容，输入一些不符合格式的字符串是否符合需求？
      • 时刻型的时长极限值（比方视频会议的时长能否抵达100年？）、时刻最值（比方预定了一个100年后的视频会议？）、时刻距离的粒度等等（比方距离1ms的时刻开端一次录制？）
      • 列表类型的极值，这或许是最简单被忽略的特点了，比方一次性传入一个长度是100w的列表？ 这显着不合理，那么当你想要对这个列表长度做限制的时分，天然就会发现这部分需求产品定义鸿沟值，或许分批处理
• 状况改变后的收效时机
  • 更改了状况值，是对其时视频会议当即收效，仍是对下场视频会议才收效？
• 状况收效后，会对哪些模块有影响
• 状况改变失利时，需求履行什么回退操作
  • 比方，有人入会失利了，要通知xxx

需求注意的是，尽管上面列出了很多剖析的维度，但并不是每个特点都会有这些维度。上面列出的只是一些可供参考的范围，只是供给了一些剖析的方向，必定不会是最全面的，在剖析时仍是要结合事务需求来剖析。

这么剖析有什么优劣？

优势

• 这套办法在我实际工作中运用了有两年多了，按这套办法履行下来，基本能做到需求的核心场景不遗失，鸿沟场景少遗失，对后续的开发、测验环节都比较简单达到一致。
• 便利构成测验用例。作为研制也需求规划测验用例，否则你怎样知道你写的代码是不是现已满意了要求？
• 便于笼统出范畴目标。范畴目标是体系规划的根底，有了范畴目标，你能够很便利地一致术语，也能够很便利地和所有需求相关方进行评论。包含但不限于后端、前端、客户端、测验、产品司理等同事。
• 便于后续的留存。假设几个月乃至一年后再回看这个需求，只看产品司理的几页需求并不能很快地看出需求的事务规矩。可是看你的需求剖析能够在短时刻内了解其时的需求。当然，关于其他想要接手这个需求的新人来说，也非常友爱。

劣势

• 需求研制同学有一定的仔细和耐心。
• 需求和产品司理，或许是真正运用的用户有充沛的交流。
• 需求剖析的耗时会比较之前耗时长一点，可是关于后续的研制流程来说，把时刻花在有办法指导的需求剖析上，绝比照在后续流程中发现需求讹夺导致返工要值得。