Ddd Architecture Evaluator

DDD Architecture Evaluator

Architecture evaluation & evolution — systematically assess DDD health, quantify technical debt, and plan architecture evolution. Supports any project type (Java/Go/Python/TS/.NET) with a structured, repeatable process.

When to read

打开此文档参考流程时可以开始评估。当用户问及架构评估、DDD 成熟度、技术债务量化或架构演进时参考：

• "帮我评估一下项目架构" → 直接开始 Workflow
• "我们的 DDD 做得怎么样" → 从成熟度评估开始
• "技术债务太高了怎么办" → 从技术债务量化开始
• "需要从 MVC 迁移到 DDD" → 从演进路线图开始

Workflow

Step 1: Assess Maturity
  → Run 5-level DDD maturity checklist (L1 → L5)
  → Identify current level vs target level (L3 is sufficient for most projects)
  → Output: Maturity level + per-level pass/fail + key gaps

Step 2: Evaluate Fitness
  → Score 5 dimensions: Business Alignment (25%), Team Fit (25%),
    Technology Fit (20%), Evolution Capability (15%), Delivery Efficiency (15%)
  → Calculate weighted fitness score
  → Output: Dimension scores + total fitness + green/yellow/orange/red rating

Step 3: Quantify Debt
  → Structural debt (P0, weight 0.5) — layer violations, circular deps, anemic entities
  → Design debt (P1, weight 0.3) — oversized aggregates, missing VOs/events
  → Testing debt (P2, weight 0.2) — domain unit test coverage
  → Output: Total debt score + health rating (green/mild/moderate/severe)

Step 4: Plan Evolution
  → 4-phase roadmap: Emergency (1-2w) → Short-term (2-4w) →
    Mid-term (1-3m) → Long-term (ongoing)
  → Migration risk assessment with Strangler Fig strategy
  → Output: Phased roadmap + risk matrix + next assessment date

Boundary

✅ 擅长处理

⚠️ 需要条件

1. 项目有代码可审：项目已运行一段时间，有实际代码库（全新项目建议用 ddd-architecture-selector） 2. 团队可提供项目背景：需要参考架构文档、代码结构、团队规模等信息 3. 明确的评估目标：建议指定评估焦点（整体成熟度 / 特定模块评估 / 迁移可行性）

❌ 不适用 / 超出范围

1. 代码级审查 → 使用 ddd-code-reviewer（反模式检测、分层合规检查） 2. 新项目架构选型 → 使用 ddd-architecture-selector（5 种架构对比决策矩阵） 3. DDD 入门学习 → 使用 ddd-architecture-awesome（概念速查、充血vs贫血对比） 4. 架构具体落地实现 → 分别使用 ddd-architecture-layered / onion / hexagonal / clean / cola

Security & 安全说明

本 Skill 是非侵入式分析框架。评估时不访问代码库、不收集项目数据、不上传任何信息。所有评估结果基于用户提供的上下文在当前对话中完成，不存储、不传输至第三方。用户自行决定是否披露项目结构信息。

DDD Maturity 5-Level Model

完整逐级检查清单见 maturity-levels-detail.md。

Architecture Fitness 5-Dimension Assessment

Total Fitness = BA×0.25 + TF×0.25 + TechF×0.20 + EC×0.15 + DE×0.15

Score interpretation:
  ≥ 4.0 → 🟢 Excellent
  3.0-3.9 → 🟡 Adequate
  2.0-2.9 → 🟠 Concerning
  < 2.0  → 🔴 Critical

See fitness-assessment-template.md for full scoring rubrics and assessment prompts.

Technical Debt Quantification

Category Breakdown

Calculation

Total Debt = Structural×0.5 + Design×0.3 + Testing×0.2

详细方法论和计算示例见 debt-calculation-guide.md。

4-Phase Evolution Roadmap

Traditional 3-Layer → DDD 4-Layer → DDD + Rich Domain → Hexagonal/Clean → Microservices + DDD

Migration Risk Assessment

Pre-Migration Checklist

• ☐ Architecture documented (C4 / ADR)
• ☐ Business complexity assessment done
• ☐ Team DDD knowledge assessed
• ☐ Migration scope defined (full vs incremental)
• ☐ Target architecture agreed (team + stakeholders)
• ☐ Rollback plan established (≤ 4 hours)

Strangler Fig — New features → target arch; old features → keep + gradually replace; core aggregates → migrate first.

Risk Matrix

See migration-risk-checklist.md for full migration assessment templates.

Gotchas

常见评估陷阱见 references/gotchas.md。

FAQ

Keywords

DDD maturity, architecture fitness, technical debt, architecture evolution, migration assessment, Strangler Fig, bounded context, CQRS, Event Sourcing, architecture decision record, ADR, technical debt quantification, 架构评估, 成熟度模型, 技术债务量化, 架构演进, 迁移风险, 架构适配度, 分层合规

References

• maturity/assessment-workflow.md — Maturity assessment preparation, session workflow, and common traps
• maturity/maturity-levels-detail.md — Per-level detailed checklists with scoring
• fitness/scoring-rubric.md — Scoring rubric with context-based calibration
• fitness/fitness-assessment-template.md — 5-dimension scoring rubrics and prompts
• debt/repayment-strategies.md — Debt repayment strategies and prioritization matrix
• debt/debt-calculation-guide.md — Technical debt methodology with examples
• migration/strangler-fig-detailed.md — Detailed Strangler Fig migration planning
• migration/migration-risk-checklist.md — Migration readiness checklist and risk matrix
• evolution-cases.md — Real-world evolution case studies (e-commerce, FinTech, SaaS)
• code-smells-diagnosis.md — Architecture anti-patterns and diagnosis
• migration-path.md — 6-step MVC-to-DDD migration path
• partme-11-ddd-refactoring.md — DDD refactoring case study with enterprise modeling
• gotchas.md — 评估常见陷阱（评分偏差、迁移成本、团队能力等）

Architecture Evaluation Report — Cloud-Native B2B Platform

Date: 2026-05-29 Project: PartMe Connect (Kubernetes + Go microservices, 12 developers) Evaluator: DDD Architecture Evaluator

Maturity Level: 3 (Applied)

Fitness Assessment

Fitness Score: 3.45/5 🟡 Adequate

Technical Debt: 34.2 🟡 Mild

Recommendations

• Split API gateway per BC (BFF pattern)
• Add explicit context mapping documentation
• Introduce CQRS for the analytics read model

Architecture Evaluation Report — E-Commerce Platform

Date: 2026-05-29 Project: PartMe Shop (Spring Boot + MyBatis, 15 developers) Evaluator: DDD Architecture Evaluator

Maturity Level: 2 (Aware)

Fitness Assessment

Overall Fitness: (3×0.25 + 3×0.25 + 4×0.20 + 2×0.15 + 3×0.15) = 3.05/5

Technical Debt

Evolution Roadmap

Migration Risk

Next Assessment: 2026-08-29 (quarterly)

Architecture Evaluation Report — EdTech SaaS Platform

Date: 2026-05-29 Project: LearnHub (Python Django + PostgreSQL, 18 developers) Evaluator: DDD Architecture Evaluator

Maturity: 2 (Aware)

Fitness Score: 2.45/5 🟠 Concerning

Technical Debt: 52.0 🟠 Moderate

Recommendations

• Apply Anti-Corruption Layer between Django models and domain
• Extract Assessment as first bounded context (highest ROI)
• Introduce course catalog as value objects (CourseId, LessonId)
• Phase migration: ACL → Assessment BC → Enrollment events → Course BC

Architecture Evaluation Report — FinTech Core Banking

Date: 2026-05-29 Project: FinCore (EJB + Oracle PL/SQL, 50+ developers) Evaluator: DDD Architecture Evaluator

Maturity Level: 1 (Ad Hoc)

Fitness Assessment

Overall Fitness: (2×0.25 + 1×0.25 + 1×0.20 + 1×0.15 + 1×0.15) = 1.25/5

Technical Debt

Evolution Roadmap

Migration Risk

Next Assessment: 2026-08-29 (quarterly)

Architecture Evaluation Report — Online Gaming Platform

Date: 2026-05-29 Project: GameVerse (C# .NET + Redis, 15 developers) Evaluator: DDD Architecture Evaluator

Maturity: 3 (Applied)

Fitness Score: 4.10/5 🟢 Excellent

Technical Debt: 15.8 🟢 Healthy

Key Strength

• Player aggregate is a textbook DDD example with domain events, value objects, and rich behavior
• Match aggregate has proper event-sourced state reconstruction

Minor Issues

• Tournament ↔ Match cross-aggregate refs via ID but some direct object refs remain
• Add Automated ArchUnit validation in CI/CD pipeline

Architecture Evaluation Report — Healthcare HIS System

Date: 2026-05-29 Project: MedCore (Spring Boot + RabbitMQ, Python ML services, 25 developers) Evaluator: DDD Architecture Evaluator

Maturity: 2 (Aware)

Fitness Score: 2.70/5 🟠 Concerning

Technical Debt: 48.5 🟠 Moderate

Key Issues & Recommendations

• Domain framework leak: JPA annotations in domain entities
• Cross-aggregate coupling: Patient → Appointment direct DB joins
• Missing domain events: No AppointmentScheduled or LabOrderPlaced events
• Phase 1: Extract JPA to Infrastructure; make domain POJO-only (2 weeks)
• Phase 2: Define aggregate boundaries; introduce ID-only cross-refs (3 weeks)

Architecture Evaluation Report — IoT Device Management

Date: 2026-05-29 Project: SensorHub (Python FastAPI + MQTT, 10 developers) Evaluator: DDD Architecture Evaluator

Maturity: 2 (Aware)

Fitness Score: 3.45/5 🟡 Adequate

Technical Debt: 22.1 🟡 Mild

Recommendations

• Formalize Device aggregate boundary (Device/Sensor/Reading)
• Move rule evaluation into a dedicated Bounded Context
• Add DeviceRegistered, AlertTriggered domain events

Architecture Evaluation Report — Legacy System Assessment

Date: 2026-05-29 Project: Retail POS Legacy (ASP.NET + SQL Server, 8 developers, maintain-only mode) Evaluator: DDD Architecture Evaluator

Maturity Level: 1 (Ad Hoc)

Fitness Assessment

Overall Fitness: (3×0.25 + 2×0.25 + 2×0.20 + 1×0.15 + 2×0.15) = 2.10/5

Technical Debt

Evolution Roadmap

Migration Risk

Recommendation: Start greenfield development for the new system. Do NOT refactor in-place — the legacy codebase is beyond incremental repair. Use Strangler Fig to route traffic to the new system over 12 months.

Next Assessment: 2026-06-29 (1 month — urgency due to tech EOL risk)

Architecture Evaluation Report — Logistics Platform

Date: 2026-05-29 Project: ShipFlow (Node.js + MongoDB, 8 developers) Evaluator: DDD Architecture Evaluator

Maturity: 1 (Ad Hoc)

Fitness Score: 2.50/5 🟠 Concerning

Technical Debt: 55.3 🟠 Moderate

Recommendations

• Start with Event Storming to identify bounded contexts
• Extract Tracking BC first (highest churn)
• Introduce value objects (TrackingStatus, GeoLocation, Money)
• Adopt DDD Layered before considering microservices

Architecture Evaluation Report — SaaS Multi-Tenant Platform

Date: 2026-05-29 Project: PartMe Workspace (COLA v4, 20 developers) Evaluator: DDD Architecture Evaluator

Maturity Level: 3 (Applied)

Fitness Assessment

Overall Fitness: (4×0.25 + 4×0.25 + 4×0.20 + 3×0.15 + 4×0.15) = 3.85/5

Technical Debt

Evolution Roadmap

Migration Risk

Next Assessment: 2026-08-29 (quarterly)

架构反模式与气味 — 诊断+修复

贫血领域模型

Repository per Table

泄露基础设施

God Aggregate（上帝聚合）

跳过 UseCase

CRUD Thinking

不成熟的 CQRS

跨聚合事务

值对象滥用（设计气味）

修复优先级

P0（阻止合并）：
  1. 领域层去框架化
  2. 切断循环依赖
  3. 修复跨聚合引用

P1（下个版本前）：
  4. Repository 返回聚合根
  5. Controller 去业务化
  6. App 层去 SQL

P2（持续改进）：
  7. 聚合瘦身（>5 实体 → 拆分）
  8. 补充领域事件
  9. String → Value Object 替换

Technical Debt Calculation Guide

Debt Identification Methods

Structural Debt (P0) — Weight: 0.5

Structural Debt Score = Σ(metric_scores) / 4
Score range: 0-100

Design Debt (P1) — Weight: 0.3

Design Debt Score = Σ(metric_scores) / 4
Score range: 0-100

Testing Debt (P2) — Weight: 0.2

Testing Debt Score = Σ(metric_scores) / 3
Score range: 0-100

Final Calculation

Total Debt = Structural × 0.5 + Design × 0.3 + Testing × 0.2

Thresholds:
  ≤ 20  → 🟢 Healthy (no action needed)
  21-40 → 🟡 Mild (schedule repayment)
  41-60 → 🟠 Moderate (create repayment plan this quarter)
  > 60  → 🔴 Severe (start refactoring immediately)

Example Calculation

Structural:
  Layer violations: 12 files / 50 total = 24%
  Circular dependencies: 2 cycles × 5 = 10
  Anemic entities: 5/8 = 62.5%
  Average: (24 + 10 + 62.5) / 4 = 24.1

Design:
  Oversized aggregates: 2/6 = 33.3%
  Missing events: 3/10 = 30%
  VO missing rate: 40%
  Cross-aggregate refs: 1 × 3 = 3
  Average: (33.3 + 30 + 40 + 3) / 4 = 26.6

Testing:
  Domain coverage: 100 - 45% = 55
  Aggregate root testing: 100 - (3/6 × 100) = 50
  Integration testing: 100 - (5/12 × 100) = 58.3
  Average: (55 + 50 + 58.3) / 3 = 54.4

Total = 24.1 × 0.5 + 26.6 × 0.3 + 54.4 × 0.2
      = 12.05 + 7.98 + 10.88
      = 30.91 → 🟡 Mild

Architecture Evolution — Real-World Cases

Case 1: E-Commerce Platform — MVC to DDD Layered

Context: 3-year old e-commerce platform, 15 developers, Spring Boot + MyBatis.

Initial State: Traditional 3-layer MVC. OrderService has 2,500 lines. Entity classes are anemic.

Trigger for Evaluation: New feature (flash sales) requires complex inventory logic. Monolithic OrderService is the bottleneck.

Evaluation Result:

• Maturity: Level 2 (Aware) — partial value objects, no aggregates
• Debt: 52 (Moderate 🟠)
• Recommendation: DDD Layered + Strangler Fig

Evolution Phases:

Phase 1 (2 weeks): Extract core aggregates
  → Order aggregate: Order(shipTo, items, total, status)
  → Inventory aggregate: Inventory(sku, quantity, reserved)
  → Cut circular dependency between Order ↔ Inventory

Phase 2 (3 weeks): Rich domain model
  → Order.pay(), Order.cancel(), Order.ship()
  → Value objects: Money, OrderStatus, ShippingAddress
  → Domain events: OrderPlaced, PaymentConfirmed

Phase 3 (4 weeks): Bounded context split
  → Order BC: order-service (new)
  → Inventory BC: inventory-service (new)
  → Payment BC: payment-service (new)
  → Event communication via RabbitMQ

Phase 4 (2 weeks): CQRS L1 for order read model
  → OrderQueryService (optimized for listing/aggregation)
  → Shared write DB, dedicated read views

Outcome After 3 Months:

• Maturity: Level 3 (Applied)
• Debt: 18 (Healthy 🟢)
• New feature delivery: 2 weeks → 4 days
• Team confidence: High

Case 2: FinTech Core — Hexagonal Migration

Context: 8-year old banking core system, 50+ developers, multiple integration points.

Initial State: Monolith with EJB + Oracle PL/SQL stored procedures. Business logic in DB.

Trigger for Evaluation: Regulatory requirement changes every 6 months. Current system takes 3 months to implement any change.

Evaluation Result:

• Maturity: Level 1 (Ad Hoc)
• Debt: 78 (Severe 🔴)
• Recommendation: Hexagonal Architecture + Strangler Fig over 12 months

Evolution Phases:

Phase 1 (2 months): Port identification
  → Define inbound ports (UseCases) for top 5 core flows
  → Define outbound ports (AccountRepository, LedgerGateway)
  → Create anti-corruption layer for legacy EJB

Phase 2 (3 months): Account domain — first port
  → New Account aggregate in Hexagonal style
  → Parallel run: new system reads from legacy, writes to new DB
  → Canary release for account balance queries (non-critical reads)

Phase 3 (4 months): Transaction domain
  → Transaction aggregate + Event Sourcing for audit trail
  → CQRS L2: write DB (EventStore) + read DB (Postgres materialized views)
  → Integration with external settlement systems via outbound ports

Phase 4 (3 months): Full cutover
  → Migrate remaining flows (interest calculation, fee assessment)
  → Sunset legacy modules after 6-month parallel run
  → Architectural fitness monitoring dashboard

Outcome After 12 Months:

• Maturity: Level 4 (Scaled)
• Debt: 28 (Mild 🟡)
• Regulatory change implementation: 3 months → 3 weeks

Case 3: SaaS Platform — COLA to Event-Driven

Context: Fast-growing SaaS startup, 20 developers, rapid feature iteration.

Initial State: COLA v4 architecture, well-structured, but cross-module coupling growing.

Trigger for Evaluation: User sync between modules causes cascading failures. Team wants decoupled event-driven architecture.

Evaluation Result:

• Maturity: Level 3 (Applied)
• Debt: 15 (Healthy 🟢) — well-maintained, but cross-module coupling identified
• Recommendation: Add event bus + gradually migrate to event-driven cross-BC communication

Evolution:

Phase 1 (2 weeks): Introduce DomainEventBus (in-process)
Phase 2 (4 weeks): Extract first event-driven flow (UserCreated → ProvisionTenant)
Phase 3 (6 weeks): Replace direct module calls with events
Phase 4 (ongoing): Add resilience patterns (dead letter, retry, idempotency)

Architecture Fitness Assessment Template

5-Dimension Scoring

Dimension 1: Business Alignment

Template Prompt:

Business Alignment Assessment:
- Project type (CRUD / Complex domain / Real-time / Data-heavy):
- Business complexity score (1-5):
- Current architecture complexity score (1-5):
- Gap: {complexity_score - architecture_score}
- Notes:

Dimension 2: Team Fit

Template Prompt:

Team Fit Assessment:
- Team size:
- Average DDD experience (years):
- Ramp-up time for new members (weeks):
- Code convention violation rate (%):
- Notes:

Dimension 3: Technology Fit

Template Prompt:

Technology Fit Assessment:
- Primary framework/ORM:
- Architecture pattern:
- Known friction points:
- Workarounds in use:
- Notes:

Dimension 4: Evolution Capability

Template Prompt:

Evolution Capability Assessment:
- BC count:
- Module coupling score (1-5):
- Average refactoring effort (points):
- New feature delivery cycle (weeks):
- Notes:

Dimension 5: Delivery Efficiency

Template Prompt:

Delivery Efficiency Assessment:
- Average feature cycle time (days):
- Architecture overhead (%):
- Deployment frequency:
- Bottleneck layer:
- Notes:

Overall Score

Total Fitness = (BA × 0.25 + TF × 0.25 + TT × 0.20 + EC × 0.15 + DE × 0.15)

Weighting rationale:
- Business Alignment & Team Fit: 25% each (people + purpose)
- Technology Fit: 20% (tools)
- Evolution Capability & Delivery Efficiency: 15% each (outcomes)

DDD Architecture Evaluation Gotchas

常见评估陷阱，规避误判。

架构评估 ≠ 代码审查

评估关注架构结构、依赖方向、成熟度，而非具体代码质量。代码级问题交给 ddd-code-reviewer。

评分只是指标，不是目标

5 级成熟度评分是相对指标，用于指导改进方向。Level 3 (Applied) 对大多数项目已经足够，强求 Level 5 会过度设计。

忽视迁移成本

指出"需要迁移到 Hexagonal"但没有量化成本和时间。每次评估必须附带分阶段路线图和人力估算。

评估频率失当

月度评估太频繁消耗精力，年度太稀疏错过信号。推荐季度评估 + 重大业务变更时触发评估。

单点评估偏差

单人评估结果可能带有主观偏见。建议至少 2 人独立评估后协商综合结果，可结合 ArchUnit 自动化检查。

只评不跟

报告出完不追踪改进。下次评估必须对比上次改进项完成情况。建议建立 debt dashboard 追踪。

忽略团队能力

推荐了整洁架构但团队只有 3 人且 DDD 零经验，等于把项目推向灾难。架构决策必须匹配团队技能。

一刀切式建议

不同限界上下文可能有不同成熟度。建议对核心域做 Level 3+，支撑域可接受 Level 1-2。

用旧指标评价新架构

迁移后的新模块不应再使用三层架构的指标衡量（如 Service 行数），需建立新的评价基准。

忽略已有资产

完全废弃老代码去重构，而不是用 Strangler Fig 渐进替换。评估应优先考虑保留价值，而非大拆大建。

过度依赖工具

ArchUnit 是检查"约定是否被违反"的工具，不能替代人为判断"约定是否合理"。自动化检查 + 人工审查缺一不可。

把 CQRS 当银弹

不是所有项目都要 CQRS。80% 查询 + 20% 写入的简单场景不需要 CQRS。从 L1 模型分离开始，不要直接跳到 L3 Event Sourcing。

DDD Maturity Levels — Detailed Checklist

Level 1: Ad Hoc (初始级)

Score: 1 point if ≥ 5 items match.

Level 2: Aware (认知级)

Score: 2 points if ≥ 3 items match.

Level 3: Applied (实践级)

Score: 3 points if ≥ 5 items match.

Level 4: Scaled (规模化级)

Score: 4 points if ≥ 5 items match.

Level 5: Optimized (优化级)

Score: 5 points if ≥ 5 items match.

Maturity Score Calculation

Overall Maturity = max(Level where ≥ threshold check items pass)

Example:
  L1 items pass: 7/7 ✓
  L2 items pass: 4/7 ✓
  L3 items pass: 6/7 ✓
  L4 items pass: 3/7 ✗ (need 5)
  → Maturity Level: 3 (Applied)

从 MVC/贫血到 DDD/充血 — 迁移路径

6 步渐进迁移

传统 MVC（贫血模型）
  ↓ Step 1: 识别限界上下文与聚合
  ↓ Step 2: 提取值对象（Money → Email → PhoneNumber）
  ↓ Step 3: 把业务规则从 Service 搬到 Entity（充血）
  ↓ Step 4: 引入 Repository 接口（Domain 定义，Infra 实现）
  ↓ Step 5: 用领域事件替代直接 Service 调用（跨聚合）
  ↓ Step 6: 把 Controller 变成薄适配器
DDD 分层架构（充血模型）

Step 1: 识别限界上下文与聚合

操作：

• 用事件风暴识别领域事件和命令
• 找出聚合根（有独立生命周期、全局唯一 ID）
• 划定聚合边界（一次事务只改一个聚合）

产出：限界上下文清单 + 聚合清单

Step 2: 提取值对象

操作：

• 把 String status → OrderStatus 枚举/类
• 把 BigDecimal amount + String currency → Money 值对象
• 把 String email → Email 值对象（含格式校验）

收益：类型安全、自校验、业务语义清晰

Step 3: 充血化

操作：

• 把 OrderService.pay(orderId) 中的逻辑移到 Order.pay()
• 把 OrderService.cancel(orderId, reason) 移到 Order.cancel(reason)
• 把 OrderService.calculateTotal(orderId) 移到 Order.calculateTotal()

检验标准：Order 实体不再只有 getter/setter

Step 4: 引入 Repository 接口

操作：

• 在 Domain 层定义 interface OrderRepository { save(); findById(); }
• 在 Infrastructure 层实现（JPA/MyBatis）
• 应用服务注入接口，不直接依赖 ORM

检验：Domain 层无 @Entity, @Repository, @Table

Step 5: 领域事件替代直接调用

操作：

• 跨聚合操作改为 addDomainEvent(new OrderPaid(orderId))
• 应用层统一发布领域事件
• 事件处理器完成后续操作

收益：聚合解耦，支持 1→N 订阅

Step 6: Controller 薄化

操作：

• Controller 只做协议转换（HTTP → Command）
• 业务逻辑全部在 Domain + Application
• DTO 转换在 Application 层完成

检验：Controller 无 if/else 业务判断

源代码

Migration Risk Assessment Checklist

Pre-Migration Readiness

Risk Scoring Matrix

Risk = Impact × Probability (1-5 each)

Strangler Fig Migration Strategy

Step 1: Route new features to target architecture
Step 2: Wrap legacy modules with anti-corruption layer
Step 3: Migrate core aggregates first (highest ROI)
Step 4: Gradually replace legacy modules
Step 5: Remove legacy when all consumers migrated

Migration Phasing Template

Phase | Duration | Scope | Risk | Rollback
------|----------|-------|:----:|---------
Pilot | 1-2 weeks | Single aggregate (read-only) | Low | Disable feature flag
Wave 1 | 2-4 weeks | Core write operations | Medium | Traffic switch back
Wave 2 | 1-2 months | Full bounded context | High | Canary release
Wave 3 | 2-3 months | Remaining modules | Medium | Per-module rollback

Architecture-Specific Risks

Post-Migration Validation

进入两千年后，随着互联网应用的快速发展，很多传统企业开始触网，建设自己的互联网电商平台。后来又随着微信和 App 等移动互联应用的兴起，又形成了新一轮的移动应用热潮。这些移动互联应用大多面向个人或者第三方，市场和需求变化快，需要以更敏捷的速度适应市场变化，为了保持快速响应能力和频繁发版的要求，很多时候这些移动互联网应用是独立于传统核心系统建设的，但两者承载的业务大部分又都是同质的，因此很容易出现业务能力重叠的问题。

阿里巴巴过去带动了传统企业向互联网电商转型。而如今又到了一个新的历史时期，在阿里巴巴提出中台战略后，很多企业又紧跟它的步伐，高举中台大旗，轰轰烈烈地开始了数字化转型之路。

那么传统企业在中台转型时，该如何从错综复杂的业务中构建中台业务模型呢？今天我就用一个传统企业中台建模的案例，带你一起用 DDD 的设计思想来构建中台业务模型。

传统企业应用分析

互联网电商平台和传统核心应用，两者面向的渠道和客户不一样，但销售的产品却很相似，它们之间的业务模型既有相同的地方，又有不同的地方。

现在我拿保险行业的互联网电商和传统核心应用来做个对比分析。我们看一下下面这张图，这两者在业务功能上会有很多相似和差异，这种相似和差异主要体现在四个方面。

1. 核心能力的重复建设。

由于销售同质保险产品，二者在核心业务流程和功能上必然相似，因此在核心业务能力上存在功能重叠是不可避免的。传统保险核心应用有报价、投保、核保和出单功能，同样在互联网电商平台也有。这就是核心能力的重复建设。

2. 通用能力的重复建设。

传统核心应用的通用平台大而全，通常会比较重。而互联网电商平台离不开这些通用能力的支撑，但为了保持敏捷性，一般会自己建设缩小版的通用功能，比如用户、客户等。这是通用能力的重复建设。

3. 业务职能的分离建设。

有一类业务功能，在互联网电商平台中建设了一部分，在传统核心应用中也建设了一部分，二者功能不重叠而且还互补，组合在一起是一个完整的业务职能。比如缴费功能，互联网电商平台主要面向个人客户，于是采用了支付宝和微信支付的方式。而传统核心应用主要是柜台操作，仍在采用移动 POS 机的缴费方式。二者都是缴费，为了保证业务模型的完整性，在构建中台业务模型时，我们可以考虑将这两部分模型重组为一个完整的业务模型。

4. 互联网电商平台和传统核心功能前后完全独立建设。

传统核心应用主要面向柜台，不需要互联网电商平台的在线客户、话务、订单和购物车等功能。而互联网电商平台主要面向个人客户，它不需要后端比较重的再保、佣金、打印等功能。在构建中台业务模型时，对这种情况应区别对待，将面向后端业务管理的应用沉淀到后台，将前端能力构建为面向互联网渠道的通用中台，比如订单等。

如何避免重复造轮子？

要避免重复建设，就要理解中台的理念和思想。前面说了“

中台是企业级能力复用平台

”用白话说就是重复使用，就是要避免重复造轮子的事情。

中台的设计思想与“高内聚、低耦合”的设计原则是高度一致的。高内聚是把相关的业务行为聚集在一起，把不相关的行为放在其它地方，如果你要修改某个业务行为，只需要修改一处。对了！中台就是要这样做，按照“高内聚、松耦合”的原则，实现企业级的能力复用！

那如果你的企业遇到了重复造轮子的情况，应该怎么处理？

你需要站在企业高度，将重复的需要共享的通用能力、核心能力沉淀到中台，将分离的业务能力重组为完整的业务板块，构建可复用的中台业务模型。前端个性能力归前端，后端管理能力归后台。建立前、中、后台边界清晰，融合协作的企业级可复用的业务模型。

如何构建中台业务模型？

我们可以用 DDD 领域建模的方法来构建中台业务模型。你可以选择两种建模策略：自顶向下和自底向上的策略。具体采用哪种策略，你需要结合公司的具体情况来分析，下面我就来介绍一下这两种策略。

1. 自顶向下的策略

第一种策略是自顶向下。这种策略是先做顶层设计，从最高领域逐级分解为中台，分别建立领域模型，根据业务属性分为通用中台或核心中台。领域建模过程主要基于业务现状，暂时不考虑系统现状。

自顶向下的策略适用于全新的应用系统建设，或旧系统推倒重建的情况。

由于这种策略不必受限于现有系统，你可以用 DDD 领域逐级分解的领域建模方法。从下面这张图我们可以看出它的主要步骤：第一步是将领域分解为子域，子域可以分为核心域、通用域和支撑域；第二步是对子域建模，划分领域边界，建立领域模型和限界上下文；第三步则是根据限界上下文进行微服务设计。

2. 自底向上的策略

第二种策略是自底向上。这种策略是基于业务和系统现状完成领域建模。首先分别完成系统所在业务域的领域建模；然后对齐业务域，找出具有同类或相似业务功能的领域模型，对比分析领域模型的差异，重组领域对象，重构领域模型。这个过程会沉淀公共和复用的业务能力，会将分散的业务模型整合。

自底向上策略适用于遗留系统业务模型的演进式重构。

下面我以互联网电商和传统核心应用的几个典型业务域为例，带你了解具体如何采用自底向上的策略来构建中台业务模型，主要分为这样三个步骤。

第一步：锁定系统所在业务域，构建领域模型。

锁定系统所在的业务域，采用事件风暴，找出领域对象，构建聚合，划分限界上下文，建立领域模型。看一下下面这张图，我们选取了传统核心应用的用户、客户、传统收付和承保四个业务域以及互联网电商业务域，共计五个业务域来完成领域建模。

从上面这张图中，我们可以看到传统核心共构建了八个领域模型。其中用户域构建了用户认证和权限两个领域模型，客户域构建了个人和团体两个领域模型，传统收付构建了 POS 刷卡领域模型，承保域构建了定报价、投保和保单管理三个领域模型。

互联网电商构建了报价、投保、订单、客户、用户认证和移动收付六个领域模型。

在这些领域模型的清单里，我们可以看到二者之间有很多名称相似的领域模型。深入分析后你会发现，这些名称相似的领域模型存在业务能力重复，或者业务职能分散（比如移动支付和传统支付）的问题。那在构建中台业务模型时，你就需要重点关注它们，将这些不同领域模型中重复的业务能力沉淀到中台业务模型中，将分散的领域模型整合到统一的中台业务模型中，对外提供统一的共享的中台服务。

第二步：对齐业务域，构建中台业务模型。

在下面这张图里，你可以看到右侧的传统核心领域模型明显多于左侧的互联网电商，那我们是不是就可以得出一个初步的结论：传统核心面向企业内大部分应用，大而全，领域模型相对完备，而互联网电商面向单一渠道，领域模型相对单一。

这个结论也给我们指明了一个方向：首先我们可以将传统核心的领域模型作为主领域模型，将互联网电商领域模型作为辅助模型来构建中台业务模型。然后再将互联网电商中重复的能力沉淀到传统核心的领域模型中，只保留自己的个性能力，比如订单。中台业务建模时，既要关注领域模型的完备性，也要关注不同渠道敏捷响应市场的要求。

有了上述这样一个思路，我们就可以开始构建中台业务模型了。

我们从互联网电商和传统核心的领域模型中，归纳并分离出能覆盖两个域的所有业务子域。通过分析，我们找到了用户、客户、承保、收付和订单五个业务域，它们是可以用于领域模型对比分析的基准域。

下面我以客户为例，来给你讲一下客户中台业务模型的构建过程。

互联网电商客户主要面向个人客户，除了有个人客户信息管理功能外，基于营销目的它还有客户积分功能，因此它的领域模型有个人和积分两个聚合。

而传统核心客户除了支持个人客户外，还有单位和组织机构等团体客户，它有个人和团体两个领域模型。其中个人领域模型中除了个人客户信息管理功能外，还有个人客户的评级、重复客户的归并和客户的统一视图等功能，因此它的领域模型有个人、视图、评级和归并四个聚合。

构建多业务域的中台业务模型的过程，就是找出同一业务域内所有同类业务的领域模型，对比分析域内领域模型和聚合的差异和共同点，打破原有的模型，完成新的中台业务模型重组或归并的过程。

我们将互联网电商和传统核心的领域模型分解后，我们找到了五个与个人客户领域相关的聚合，包括：个人、积分、评级、归并和视图。这五个聚合原来分别分散在互联网电商和传统核心的领域模型中，我们需要打破原有的领域模型，进行功能沉淀和聚合的重组，重新找出这些聚合的限界上下文，重构领域模型。

最终个人客户的领域模型重构为：

个人、归并和视图三个聚合重构为个人领域模型（客户信息管理），评级和积分两个聚合重构为评级积分领域模型（面向个人客户）。到这里我们就完成了个人客户领域模型的构建了。

好像还漏掉点什么东西呢？对了，还有团队客户领域模型！其实团体客户很简单。由于它只在传统核心中出现，我们将它在传统核心中的领域模型直接拿过来用就行了。

至此我们就完成了客户中台业务模型的构建了，客户中台构建了个人、团体和评级积分三个领域模型。

通过客户中台业务模型的构建，你是否 get 到构建中台业务模型的要点了呢？总结成一句话就是：“分域建模型，找准基准域，划定上下文，聚合重归类。”

其它业务域其实也是一样的过程，在这里我就不一一讲述了，你可以自己练习一下，作为课后作业。完成后你可以对照下面这张图看一下，这就是其它业务域重构后的中台业务模型。

第三步：中台归类，根据领域模型设计微服务。

完成中台业务建模后，我们就有了下面这张图。从这张图中我们可以看到总共构建了多少个中台，中台下面有哪些领域模型，哪些中台是通用中台，哪些中台是核心中台，中台的基本信息等等，都一目了然。你根据中台下的领域模型就可以设计微服务了。

重构过程中的领域对象

上面主要是从聚合的角度来描述中台业务模型的重组，是相对高阶的业务模块的重构。业务模型重构和聚合重组，往往会带来领域对象和业务行为的变化。下面我带你了解一下，在领域模型重组过程中，发生在更底层的领域对象的活动。

我们还是以客户为例来讲述。由于对象过多，我只选取了部分领域对象和业务行为。

传统核心客户领域模型重构之前，包含个人、团体和评级三个聚合，每个聚合内部都有自己的聚合根、实体、方法和领域服务等。

互联网电商客户领域模型重构前包含个人和积分两个聚合，每个聚合包含了自己的领域对象、方法和领域服务等。

传统核心和互联网电商客户领域模型重构成客户中台后，建立了个人、团体和评级积分三个领域模型。其中个人领域模型有个人聚合，团体领域模型有团体聚合，评级积分领域模型有评级和积分两个聚合。这些领域模型的领域对象来自原来的领域模型，但积分评级是重组后的领域模型，它们原来的聚合会带着各自的领域对象，加入到新的领域模型中。

这里还要注意：部分领域对象可能会根据新的业务要求，从原来的聚合中分离，重组到其它聚合。新领域模型的领域对象，比如实体、领域服务等，在重组后可能还会根据新的业务场景和需求进行代码重构。

今天我们一起讨论了传统企业中台数字化转型，在面对多个不同渠道应用重复建设时，如何用 DDD 领域建模的思想来构建中台业务模型。中台业务建模有自顶向下和自底向上两种策略，这两种策略有自己的适用场景，你需要结合自己公司的情况选择合适的策略。

其实呢，中台业务模型的重构过程，也是微服务架构演进的过程。业务边界即微服务边界，业务边界做好了，微服务的边界自然就会很好。

Technical Debt Repayment Strategies

Strategy Selection Matrix

Structural Debt Repayment (P0)

1. Layer violations: Add ArchUnit rules, block CI for new violations 2. Circular deps: Extract shared interface or event-based communication 3. Anemic entities: Move one service method per sprint into entity 4. Framework leaks: Replace @Entity with POJO in domain; use JPA in infra only

Design Debt Repayment (P1)

1. Oversized aggregates: Identify sub-aggregates, extract with ID refs 2. Missing events: Map domain events from existing @Transactional methods 3. String → VO: Replace one field per sprint using Strangler Fig for DB columns

Fitness Scoring Rubric — Detailed Criteria

Business Alignment

Scoring Calibration

• Score 5: Architecture enables business agility. New features are easy to add.
• Score 4: Minor friction. Some adaptation needed.
• Score 3: Architecture does not actively help or hinder.
• Score 2: Architecture creates noticeable friction.
• Score 1: Architecture is a blocker. Major rework needed.

Maturity Assessment Workflow

Preparation

1. Collect sample code from each layer (Controller/Service/Domain/Infrastructure) 2. Pull architecture documentation (ADR, C4 diagrams) 3. Interview 2-3 team members about DDD understanding 4. Run automated scans (ArchUnit, JDepend) for metrics

Assessment Session

1. Per-level checklist evaluation (30 min) 2. Score calculation with evidence 3. Gap analysis: current vs target 4. Timeline estimation for each level progression

Common Assessment Traps

• Confirmation bias: Looking for evidence that confirms expected level
• Recency effect: Judging based on recently refactored modules, ignoring rest
• Scale blindness: A small project at L3 is different from an enterprise at L3

Strangler Fig Migration — Detailed Planning

Phase Breakdown

Migration Decision Tree

Want to migrate?
├─ Is business value clear?
│  ├─ Yes → Proceed with Strangler Fig
│  └─ No → Don't migrate; document decision
├─ Team capacity available?
│  ├─ Yes → Start with lowest-risk module
│  └─ No → Hire or pause; don't half-migrate
├─ Data migration needed?
│  ├─ Yes → Plan dual-write + validation
│  └─ No → Simpler cutover

Rollback Checklist

☐ Feature flag to switch traffic
☐ Dual-write to legacy DB until validated
☐ Data integrity comparison script
☐ Performance baseline recorded
☐ Max rollback time: 4 hours