DSL@core：需求代码化
目录
需求代码化，即将软件开发需求抽象为特定的领域语言，并使用管理代码一样的方式来管理需求，追踪需求的变化 。同时，为通过新的 API 来对接版本管理系统，以可视化需求，演变为看板代码化。
它具备这么一些特征：
- 使用标记语言编写内容。如 Cucumber
- 可通过版本控制系统进行版本控制。如 git
- 与编程一致的编程体验，还可以作为测试代码的一部分
- 支持集成到现有的看板系统中
- 可集成到 IDE 中协作
- 支持 Git 转换为 CRUD 接口
为了进一步实现万物即代码，它还具备这么一些特征：
- 可对需求进行重构
- 可转化为设计语言
如何实现需求即代码
设计要素：
- 设计需求代码化 DSL
- 过渡 API 设计
- REST 接口转换 SCM 接口（如 Git）
- 静态 API 生成（用于燃尽图等）
- IDE 集成看板
- DSL 可视化看板
- 删除原有的看板系统
三段式表达
三段式，大家都比较熟悉，我们可以按自己的需求，将所有的东西都转化为三段式：
- BDD 的：Given - When - Then
- UI 设计的显示 - 行动 - 响应
- 前端开发的：展示 - 事件 - 响应
- HTTP 请求的：request - handle - response
- 代码的：输入参数 - 处理 - 输出结果
- 测试的：Arrange-Act-Assert
- ……
如果不熟悉的话， 可以简单地看一下我之前设计的一个设计语言示例：
SEE HomePage
DO [Click] "Login".Button
REACT Success: SHOW "Login Success".Toast with ANIMATE(bounce)</code>
就这么简单。
最小需求模型
在我们对需求进行建模的时候，我们需要考虑一个需求的最小要素，如下：
- ID
- 开始时间
- 结束时间
- 优先级
- 状态
- 作者
- 开发者
- 标题
这个简单的 Kanban 模式。
重新设计需求的组织形式
现有的看板系统都存在一个问题，只让业务人员写一个标准答案。而缺少中间的过程设计，因此如果想降低编写需求的成本，那么应该重新设计一下需求的组织形式。现有的需求的组织形式，有：『影响地图』和『用户旅程地图』。
其实我们要做的事情很简单，即我们只有最后能可视化出『用户旅程地图』即可，然后往 DSL 添加新的字段即可。
需求 DSL 的要素
如果现有的三段式 DSL 不满足需求，那么可以回过头来看看需求的要素是什么？
- 目标。系统的业务价值，基于价值确定功能和需求的优先级。
- 人员。使用系统的人员以及业务流程和目的。
- 系统。存在什么系统，用户界面是什么样，系统间如何交付，系统的性能怎么样？
- 数据。三者的关系，从最终用户角度看到的业务数据对象、数据的生命周期、报告中数据对决策的影响。
基于这四要素，我们可以重新设计我们的需求 DSL。
NLP 建模过程
在我们的系统进一步完善之后，我们要采用 NLP（自然语言处理）对需求进行分析，从中提取上述所涉及的四要素，进而将需求转换为代码。
- 提取名词
- 抽象行为
- 关注数据及状态
- 建模
- 实例化
- ……