设计理念

通过编写 ts 的方式进行领域设计，目标是作为 ddd 建模生产力工具

遵循以下原则：

• 尽可能让代码与视图拥有相近的表达能力

• 借助 ts 代码检查保证一定的完备性

• 探索在设计的时候，如何更多地表达 WHY，而不是像传统设计图一样只表达 HOW。（工作流 + 用户故事）

低学习成本

• 必须把复杂性封装到库内，然后把使用难度保持在 js 级别（无需考虑类型）

• 渐进式的编程，有一些 api 看起来“没必要”（比如“强类型需求”的概念），这是因为目前已有的需求很简单。不需要就不用学习，但随着需求的增加，自然就用上了，这时就是“需要”了。这个过程是渐进式的。

单向工作流

• 对于特性的添加，遵循“单向工作流”原则：先设计 -> 再开始落地 -> ... 拒绝“落地影响设计”

  • 如果某些特性，哪怕可以给每个项目的落地节省 10 分钟，就可以考虑做

  • 如果某些特性，侵占了下一步工作的“职责”，那就不做

  • 例如：代码生成功能可以做，且这个功能应开始于减负，结束于减负：它的目标就是让我们在初次落地时少写一点样板代码，假如这个样板代码不太准确，我们可以先手动调整，然后在不增加领域建模负担的前提下慢慢优化功能。 这个代码生成功能绝不会是“低代码”，否则这将要求领域设计工作的复杂度与完备性将与目标编程语言的实现相近，最大的问题是，假如是低代码理念，当落地代码需要有某些调整（非领域设计问题），我们又要回过头担忧怎么改设计了，这实质上是一种返工。最终浪费的时间将远超样板代码方面节省的时间。一个好的工具应该让使用者顺利在自己应有的工作流程中一步步走下去，而不是制造麻烦。