概念

finite-state machine(FSM)，有限状态机；又称有限状态自动机（finite-state automation:FSA）。
表示有限个状态以及在这些状态之间的转移和动作等行为的数学计算模型。
有限状态机（有时称为有限状态Automaton）是可以使用硬件或软件实现的计算模型，可用于模拟顺序逻辑和一些
计算机程序。有限状态自动机会生成常规语言。有限状态机可用于模拟许多领域的问题，包括数学，人工智能，
游戏和语言学。

有两种类型的有限状态机（FSMs）：确定性有限状态机，通常称为确定性有限自动机，以及非确定性有限状态机，
通常被称为非确定性有限自动机。状态机在视觉上表示的方式有轻微的变化，但它们背后的想法源于相同的计算思想。
我们一般讨论的有限状态机就是确定性有限状态机(deterministic finite automaton：DFA)。
有限状态机包含五个概念：

• 一组有限的状态
• 有限，非空的输入
• 一系列 transition functions
• start 状态
• 一组结束状态

FSM的软件设计

对应五元素，一个DFA的软件表达可以是：

type oDfa struct {
    currentState string
    inputOpt     interface{}
    transaction  func() bool 
    targetState  string
}

type DFA struct {
    starteState  string
    stateSet     []oDfa
}

在实际实现时，需要考虑的地方会比较多：

• 将transaction分解为多个阶段，比如：Go Fsm中实现的那样(下图示)
• 需要考虑transaction执行如何满足原子性
• 需要考虑在transaction中执行失败的解决机制
• 需要考虑最终一致性的解决方案
• 。。。 正因为中间需要解决的实际问题非常多，所以在Fsm的库一般也只是满足一些基本状态迁移的特性。
  

使用Fsm方式进行软件分析

为了完整的把业务状态和它们之间的迁移关系表现出来，需要整理一份下面这样的的表格：

参考

1. Finite State Machines
2. 有限状态机 wiki

DDD战术设计要素

DDD的战术设计6个要素：值对象、实体、聚合、领域服务、仓储、工厂 每个要素的描述链接： 值对象：值对象 实体：实体 聚合：聚合 领域服务：领域服务 仓储：仓储 工厂：工厂

分层架构

分层架构一般是：UI层、应用层、领域层、基础设施层 UI层，可以理解为接口层 应用层，承接用户业务需求，串联领域功能特性 领域层，包含所有的领域对象、领域逻辑、领域流程 基础设施层，业务领域之外，给业务完成需要的支撑能力 这四层的关系是，UI层面向外部用户呈现、APP层面向用户服务、领域层则是业务底层逻辑以及这些业务逻辑实现的功能、基础设施是为领域层提供支撑。 依赖关系是：

• UI层依赖APP层
• APP层依赖领域层
• 基础设施通过实现领域层的接口，反转依赖，依赖领域层
• 领域层不依赖任何外部逻辑

DDD战术落地前的准备

在进行战术落地到分层架构前所需的前提条件是：

• 完成统一语言
• 确定BC，开发对象
• 确定BC内的要素分解，明确有哪些应用事件等
• 明确了各流程在分层架构中的交互

落地步骤和要点

将前期分析的DDD要素，落地为分成架构的代码，可以遵循以下步骤：

1. 首先，需要找到对架构全局具有影响的一个业务逻辑
2. 明确这个业务逻辑涉及到的、依赖的子流程
3. 进行子流程递归分解，直到子流程只涉及到一个领域对象
4. 编写测试用例驱动这个领域对象的实现
5. 层层向上测试驱动，直到这个子流程实现
6. 然后驱动所有子流程的实现
7. 最后驱动出这个业务流程实现

上面步骤中，需要详细说明几点： 1.

落地过程例子

参考

1. DDD进阶站训营： — 中兴通讯技术交练组组长，丁辉

需求实例化五步法

包括： 定系统、找用户、问目的、画场景、设功能 这个过程是一步一步把需求进行细化，明确，完整，以及可测的一个过程。

定系统

在定系统时，需要先描述出需求背景。再根据需求背景，结合需求新旧系统的区别，确定系统边界。
这个过程的第一步就是背景描述，这个背景包括：

• 物理实体结构（关系，一对一还是一对多这个属性通常会对软件的非功能属性产生需求）
• 逻辑结构，逻辑部分之间的关系，此时不需要详细的交互。逻辑结构有时是可以省略的。 第二步就是描述出满足需求的新旧系统的区别
  第三步就是定系统，定系统定的是承接需求团队的能力边界。在上面分析的需求背景系统中，团队的边界包括哪些。

在描述背景时，需要约束，描述的是问题，而不是解决方案。但是用户一般都是给的解决方案，所以在一开始就要识别出来哪些是用户给的方案，哪些是用户提的需求。例子：
做一套信息管理系统，这个系统中有一个采购流程，最后的审批人是仓库管理员。
仓库管理员提出： 希望在审批采购流程时，可以让采购单可编辑 软件业务员就说：你负责采购单审核，为什么要编辑这个采购单呢？ 仓库管理员就提出：如果担心我修改这个采购单，那就提供编辑的同时，把保持按钮给灰掉，禁止保存修改就可以了。
然后业务就回去让开发，去做个需求了。那么这个需求就成了开发人员茶余饭后吐槽的白痴需求了。

为了说明第三点，例子：
作为餐饮行业，用户提出能够网上进行订餐（点单），客人在预定事件到酒店就餐消费。
作为一个餐饮门店，，它的系统边界和作为一个餐饮集团公司总部分析这个需求时系统边界是不一样的。
作为集团公司可能就要包含门店选择这些餐饮门店所不具备的内容。

找用户

这个过程需要通过描述软件未实现的流程，就是此时系统内的软件都没有实现，仅描述在系统中的交互过程。需要注意的是：

• 软件未实现流程
• 需求触发包括：基本都是外部的，或者是定时器（定时器也可以转化为配置触发）
• 交互对象收到交互内容需要明确：可以满足外部交互对象进行分解问题（关键字）
• 中间的等待、同步异步等要素需要体现出来
• 明确结束流程

问目的

需求分为三个层次：

• want: 用户要的是什么
• need: 用户的需要
• win: 满足用户的内在需求 通过一个例子，可以说明这三个层次：
  一个小伙来到杂货店买电转，这个老板跟小伙的交流过程：
  guy: 我要一个电钻
  /上面是want/
  —
  boss: （店里没有电钻，所以就聊了起来）你要电钻做什么？
  guy: 要在墙上打个洞
  boss: 墙上打洞做什么？
  guy: 要在墙上挂上画
  /上面是need/
  —
  boss: 为什么要在墙上挂画？
  guy: 因为墙光秃秃的，显得冷清。我一个人，呆在家里不想这么冷清。
  /上面已经识别出了用户的内在需求 win/

上面的例子在真实场景中，存在一个问题，不能通过一直问“为什么”来挖掘用户的内在需求，因为“为什么”存在质疑的含义，所以跟用户打交道还是需要市场人员有技巧的交流。

另外目的分类：

• 业务目的
• 管理目的
• 维护目的 我们需要尽量把所有角度的用户目的都挖掘出来，一般都会包括多个业务目的。找目的需要考虑趋利避害两个方面：
• 趋利：就是希望得到的好处，需要实现的目的
• 避害：为了避免过程中出现的问题，损失，需要实现的目的

最终在问目的步骤需要输出的是每一个业务目的、管理目的或者维护目的的need和want两层，可以通用描述为：
为了达到的目的 ，希望实现能力。 这样就得到了一组细分需求。

最后，问目的的时候，要足够细致，这样后面步骤的画场景才能画的完整。

画场景

在画场景中，我们通过模型图来把每一个需求的前置条件、交互流程、后置达成目标都明确出来。形成可验收的用例。 一般我们可以选择时序图来画场景。过程中，需要对整个流程、参数进行细化，包括完整的三个部分：

• 验收准则
• 接口
• 完整的交互过程

这个画场景的过程还需要把系统在特定场景下的非功能需求挖掘出来。每个非功能指标都是在具体的场景下的。

设功能

通过前面的画场景，得到了用户的不同使用场景，以及具体的使用用例集。现在需要把不同的场景从业务领域提供的功能角度进行一次聚合。 聚合后形成这次需求涉及的功能列表。功能列表可以写成：as-for-do形式，其中do可以是多个场景聚合的内容。 之所以要做这个动作原因目前考虑有两方面，一是，当前的需求可能是对原有功能的增改动作，所以需要维护之前的功能描述文档；二是， 通过聚合梳理出的功能，更能表现业务领域模型，利于后面的软件设计。因此对于列出的功能，需要排优先级进行深度开发，也就是先完成最大价值的功能。 此时还有一个角度是，在没有顺序约束时，我们也可以选择可以决定软件架构骨架的功能进行优先开发。

参考

1. 中兴通讯教练组需求实例化教程 – 金泽锋

总体描述

在面对一个新的问题域，需要进入这个问题域进行方案设计时。周毅展示了一种方法论，我觉得这个方法可以充分发挥个人的经验和思维力，很适合经验丰富的人来使用。

方法描述

进入新领域做设计可以分为三个大步骤来进行：

1. 按照自己的理解进行理论上的设计
2. 将理论设计跟实现相对应
3. 形成方案设计

抽象设计

因为对于业务领域还不是清楚，此时的抽象设计，需要建立在理论和系统控制层面。 比如对于系统部署领域的例子

• 最初的抽象可以基于：输入内容是什么，中间运行的是什么，最终得到的是什么。
• 然后再细化具体的抽象内容：比如上面输入内容，具体这个抽象，可以是输入一份执行计划（偏向于过程

或者描述为预期系统结构（偏向于静态元素和关系）

• 假设是预期系统结构，那么就可以继续拓扑抽象的系统结构
• 。。。

最后整个系统的逻辑结构自洽了，那么再将进行下一步，与实现进行匹配。

演进出设计方案

在具有一个逻辑自洽的设计之后，再将这个设计中的内容与现实业务以及可用实现进行结合。 然后形成设计方案 /* 这部分还没有看到周毅的实例，没有比较明确的理解 */