前端架构设计

模块分层架构：

说明：

• 数据访问层 DAL(Data Access Layer): api/vuex/localStorage 等，数据存储的接口，包括但不限于本地和后台存储
 - 业务逻辑层 BLL(Business Logic Layer): detail/create/list 等，描述业务模型的场景和交互
 - 控制层 Controller: router/layout/nav/pages 等，用于连接bll和page，配置访问路由

• 视图层 Page: detail/create/list 等，各场景入口文件，统管内部所有组件
 - 基础通用层 Common: utils/components 等，全局依赖
  设计核心原则：

1. 业务逻辑和视图逻辑分离：bll聚焦在业务逻辑的数据获取、计算、合并等，而page、component则聚焦在页面的呈现结构实现上
2. 单向依赖：不同层之间保持单向依赖关系，尽量避免跨层，反向依赖等情况出现，保证分层的边界明确，避免腐坏
3. 相同层可以提取跨模块的共性进行优化：如page可以沉淀页面场景模板，controller提取通用layout和router模板，bll提取schema转换工具以适配通用的page和component等

⠀目录文件组织结构：

说明：

1. 每个领域模型都按DCI组织方式设计
2. bll最终按场景输出数据（initData）和交互行为（actions），模块场景不限于create/detail/list等常规场景，还可能包括跨模块引用的筛选弹窗、数据展示表格等

DCI详细说明：

• Data: 分为schema(fields、status等)以及data（通过api或内存中获取的form、table数据等）2类，最终会通过initData获取传递到page，在页面路由变更时会自动刷新，也可以在page通过emit事件主动刷
• Context: Detail、Create、List等按场景组合Data和Interactive，作为领域模型对外使用的接口; 场景也可能会输出跨模块依赖
- Interactive: create、edit、getList、search、approval、getList等交互行为，归纳到actions，page通过emit进行交互，尽量保证单向数据流

DCI强调2点：一是介于充血模型和贫血模型之间，简化模型同时又保留充血模型的便利（通过context来解耦，context可以注入不同的数据和行为组合）；二是补全MVC架构中缺少的交互描述
DCI能够帮助DDD更有效的落地，在前端方面，可以让开发更易理解模型，让模型的表现形式更加具体（每个模型都包含data、interactive、context）

跨模块场景示例：

说明：

• select sku dialog组件可能会被应用在pr模块，但sku展示的字段结构、search的api来源于SKU领域
• PR的context可以引入SKU的context，PR和SKU通过各自的context来解耦

⠀架构核心思想
架构设计可能会一直迭代，但是核心思想不变：

1. 将业务逻辑从组件中剥离出来，让组件的职责聚焦在结构的呈现和交互的多样性实现上，使组件变的灵活
2. 从业务逻辑中提炼核心原型，使核心业务逻辑更稳定，寿命更长
   

补充说明：
当前架构借鉴了DDD的核心思想，但距离DDD最佳实践还有较大差距
DDD最佳实践归纳：

1. 构建通用语言：定领域模型之前应该先定义业务概念，并在后续过程中持续优化，能用共同语言描述的属于同一个领域
2. 用通用语言划分领域的边界，构建领域模型
3. 使用modules、entity、service、value object等构造模型
4. 持续精炼领域模型，从通用语言和模型结构中提取核心原型，并通过上下文界定等方法保护核心原型不受边缘腐蚀
5. 最终在多次迭代中实现一个兼具稳定性和扩展性的高质量系统