# docs

**Repository Path**: sunghoo/docs

## Basic Information

- **Project Name**: docs
- **Description**: 学习总结文档。
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-07-04
- **Last Updated**: 2026-02-13

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# docs

```mermaid
sequenceDiagram
    participant User as 用户
    participant UserSvc as 用户服务 (写模型)
    participant DB_User as 用户数据库
    participant Kafka as 消息总线
    participant OrderViewBuilder as 订单视图构建服务
    participant ES as Elasticsearch (读模型)

    User->>UserSvc: POST /users/usr_abc/profile (newName: "张三丰")

    UserSvc->>DB_User: UPDATE users SET name = "张三丰" WHERE id = "usr_abc"
    DB_User-->>UserSvc: Success

    Note right of UserSvc: 核心业务完成，发布领域事件
    UserSvc->>Kafka: Publish to 'user.events' topic (Event: UserUpdated)

    Kafka-->>OrderViewBuilder: Consume 'UserUpdated' event
    Note right of OrderViewBuilder: 收到事件: { userId: "usr_abc", newName: "张三丰" }

    OrderViewBuilder->>ES: POST /order_query_view/_update_by_query
    Note right of ES: Payload: Query on user_id, Script to update user_name

    ES-->>OrderViewBuilder: { "total": 150, "updated": 150, "failures": [] }
    Note right of OrderViewBuilder: 任务成功，150个订单文档被更新
```

[Mpass](https://smpass.hyundai-autoever.com/mpass/hmgs_mpass.html)

[AutoWay](https://autowayapps.hyundai.net/appstore/app/appList.sm?companyId=null)

[Omnissa Horizon Client for Windows](https://customerconnect.omnissa.com/downloads/details?downloadGroup=CART26FQ2_WIN_2506&productId=1616&rPId=119130)



허성호:

Mapss아이디/비밀번호
9509909 A!09509909

Mpass:
질문답: 북경,김호,연대부중


一句话结论：**先请架构师定方向，再由技术专家/资深开发落地。**如果业务复杂，再加领域建模专家。

一个 DDD/领域建模专家，专注模型划分、聚合根、领域事件、边界上下文。


下面给出三类角色的**完整工作流（从需求到上线与演进）**，按顺序排列，方便你直接用于分工或写到规范里。


下面是三类角色的“最小工作流 + 产出物”对照表，便于分工：

**对照表**

1. 架构师  
- 最小工作流：澄清目标与边界 → 选架构风格 → 划分模块/上下文 → 关键链路与风险  
- 产出物：架构说明、系统分层/边界图、关键链路图、技术选型与权衡、风险清单

2. 技术专家/资深后端  
- 最小工作流：拆解架构 → 定接口契约 → 设计数据与持久化 → 落工程结构  
- 产出物：工程结构设计、接口协议与错误码、数据模型/表结构、关键实现方案

3. 领域建模专家（可选）  
- 最小工作流：业务域拆分 → 聚合/实体/值对象 → 领域事件与边界上下文  
- 产出物：领域模型图、聚合设计、上下文映射、领域事件清单

如果你想，我可以把它整理成可贴进 `README.md` 的一页协作规范。

**1. 架构师（完整工作流）**
1. 明确业务目标与范围边界（含不做清单）
2. 盘点现状系统、依赖与约束
3. 梳理关键业务场景与容量边界
4. 选定架构风格（如六边形）与总体分层
5. 划分系统边界与上下文（模块/服务/组件）
6. 设计关键链路（请求流、数据流、事件流）
7. 定技术选型与权衡（含替代方案）
8. 设计非功能（性能、可用性、容灾、安全、合规）
9. 形成演进路线图与里程碑
10. 输出架构评审材料与验收指标

**2. 技术专家/资深后端（完整工作流）**
1. 细化架构为工程结构与模块边界
2. 设计接口契约（API、事件、错误码）
3. 建立领域模型与数据模型映射
4. 设计持久化策略（表结构、索引、事务、一致性）
5. 选定框架与基础设施集成方式
6. 定关键实现方案（缓存、搜索、异步、幂等）
7. 落地工程脚手架与编码规范
8. 制定性能与容量验证方案
9. 设计监控、日志、追踪方案
10. 制定上线、灰度、回滚与运维预案

**3. 领域建模专家（完整工作流，可选）**
1. 识别业务子域与边界上下文
2. 建立通用语言与核心术语表
3. 设计领域模型（实体/值对象/聚合根）
4. 定领域事件与业务流程编排
5. 建立上下文映射与集成模式
6. 输出模型与接口对齐建议
7. 验证模型的业务一致性与演进性

如果你想，我可以把这三套流程再映射成“产出物清单 + 责任矩阵（RACI）”，便于项目管理与协作落地。