如果用一句话来总结这套架构的特点，那就是“面向用例编程，副作用和具体技术以适配器的方式和核心层隔离，保证核心层纯净”。由于严格贯彻了“代码即产品”这一理念，可以保证项目多年后也不会有腐败气息，各个模块也都比较简单，唯一值得注意的是store的设计，后面会有一些指导原则。此外还有一些没涉及到的点：

ui状态和逻辑

我的建议同样把ui纳入领域驱动，因为ui是前端更为关注的地方。这里所谓“纳入领域驱动”是指，如果一块ui足够复杂，比如一个sku生成器，一个编辑器，一个流程引擎。它们应该同样有自己的应用层和领域层(甚至作为一个独立的域，比如sku域)，同样有自己的实体。和业务实体同等对待：

  1. export function 新增节点(){}
  3. export function 设置节点属性(){}
  5. export function 节点连线() {}
  1. export interface Node {
  2.   id:string
  3.   name:string
  4.   width:number
  5.   height:number
  6. }

关于用例

有时候产品并未给出用例或者用例不完整，这时候就需要前端自己总结用例，并同步到用例图和时序图。所谓业务专家并不是一个具体职位，而是对业务逻辑了解的比较深的人，你自己也可以充当这个角色。

适用范围

本架构要求最好用例图，时序图和代码是同步更新的，并且很多情况下由开发者维护。而且，前后端虽然采用一套术语，但用例图和时序图差别很大的，需要单独维护一套，不能直接复用。所以不太适合短平快的项目，这类项目建议采用SWR一类的方案。

另外很多领域驱动概念本文都没有提到，主要是因为笔者暂时还没用到，这个以后会慢慢补充。