Ma' in wojel ba'ax ka lelo' u k'áat u ya'al
这一章节结合 Kernel 的man page中的 app(4) 和 application(3) 部分阅读。
当你写完代码实现某个特定功能之后，你希望把它变成一个 应用 —— 可以被启动停止的组件单元，同时也能被其他系统复用。
为了做到这一点，创建一个 应用回调模块 ，还需要描述这个应用如何启动和停止的文件。
因此，需要一个 应用描述说明 ，并放到 应用源文件 中。除了这些，这个文件还表明应用由哪些模块组成以及回调模块的名称。
如果你用 systools —— Erlang/OTP的代码打包工具（查看 Releases ），为每个应用准备的代码会放到特殊的目录，遵从预定义的 目录结构。
这一章节结合 stdlib man page中的 gen_event(3) 阅读，man page中详细介绍了gen_event行为模式的接口函数和回调函数。
在OTP中，事件管理器是一个可以接收并记录事件的命名对象。错误、警告和其他信息都是可以被记录的事件。
在事件管理器中，可以安装一个或多个事件处理模块。当事件处理器接收到事件通知时，所有安装的事件处理模块会处理这个事件。例如，处理错误的事件管理器默认有一个事件处理器，它会把错误日志写到终端。如果特定时期的错误信息需要保存到文件中，那么用户可以安装一个事件处理器来做这件事。当不需要写入文件时，这个事件处理器可以被删除。
事件管理器可以用进程的形式实现，而事件管理器可以实现它的回调模块。
事件管理器内部维护一个{Module, State}列表，每个Module是一个事件处理器，State是事件处理器的内部状态。
这一章节结合stdlib man page中的gen_statem(3)阅读，其中详细介绍了gen_statem行为模式的接口函数和回调函数。
注意：这是Erlang/OTP 19.0 开始提供的新行为模式，它已经经过严格的检验和慎重思考，并且稳定的运行在至少两个重量级OTP应用。根据用户反馈，可能会在Erlang/OTP 20.0中做一些不向下兼容的改动，我们希望不会如此。
现有公认的有效状态机理论并没有涉及状态转移如何触发，我们假设输出是由输入和状态函数运算，并产生一些值。
对于事件驱动的状态机，输入是一个触发状态转移的事件，输出是状态转移过程中执行的动作。有限状态机的数学模型和下面的关系集合类似：
State(S) x Event(E) -> Actions(A), State(S')
这组关系可以这样理解：
OTP设计原则用于指导以进程、模块和目录的形式组织Erlang代码的规范。
Erlang/OTP最基本的概念是监控树，由workers进程和supervisors进程组成。workers是真正执行任务的进程，我们在这里实现自己的功能；supervisors是监控进程，用于监视worker进程的行为，当worker进程异常时可以重启它。通过这种设计，worker进程可以专注工作，而supervisor监控进程尽量少的做事——它只负责监视自己负责的进程，可能是worker进程，也可能是次级监控进程。监控树按照层级组织代码，由顶层监控进程、次级监控进程和工作进程组成，很容易设计高容错系统。
在监控树中，许多进程有类似的结构和模式。例如，supervisors进程结构上类似，区别就是监控的子进程不一样。workers进程几乎都是客户端-服务端架构、有限状态机模型，以及拥有类似的事件处理机制，比如异常日志。