企业官网建设流程全解析

1. 项目概述：当DDD遇见C++，一次硬核的领域建模实践

最近在社区里看到不少关于DDD（领域驱动设计）的讨论，但大多集中在Java、C#这类“自带”丰富企业级框架的语言生态里。作为一个常年与C++打交道的开发者，我一直在思考，DDD那套强调领域模型核心地位、通过统一语言来应对复杂业务的设计思想，能不能在C++的世界里落地？毕竟，我们处理的很多高性能计算、游戏引擎、嵌入式系统，其业务逻辑的复杂程度一点也不亚于一个电商后台。为了验证这个想法，我决定用一个经典的“订单管理系统”作为试验场，进行一次从理论到代码的全程实践。这不仅仅是一个编码练习，更是一次对C++项目如何组织核心业务逻辑、如何让代码结构清晰反映业务概念的深度探索。

你可能会问，为什么是C++？在微服务大行其道的今天，用Go或Java写个订单服务不是更“主流”吗？我的考虑是，C++赋予了我们无与伦比的性能控制力和资源管理能力，这对于某些对延迟极度敏感（如高频交易订单）或需要在资源受限环境（如某些工业控制场景）中运行的订单处理核心模块来说，是至关重要的。但与此同时，C++缺乏原生的一站式ORM和依赖注入容器，这反而逼迫我们必须更纯粹地关注领域模型本身，而不是被框架“绑架”。这个项目，就是要解决如何在“裸”C++中，构建一个边界清晰、业务语义明确、易于测试和维护的领域层。

通过这个案例，你将看到如何用C++的类、值语义、智能指针等特性来诠释DDD中的实体、值对象、聚合根等核心构建块；如何设计仓储（Repository）接口来隔离领域与数据持久化细节；如何应用领域服务（Domain Service）来封装跨聚合的业务逻辑。无论你是想在学习DDD时找一个不同语言视角的参考，还是是一位寻求改善大型C++项目架构的资深工程师，相信这个具体的、可运行的案例都能给你带来启发。我们不止于谈论概念，而是会一行行地写出代码，并讨论其背后的设计取舍。

2. 核心概念映射：用C++语法诠释DDD构建块

在开始敲代码之前，我们必须建立一套统一的“语言”，即DDD的核心模式如何对应到C++的语法元素上。这个映射关系是后续所有设计的基础。

2.1 实体与值对象：生命期与等同性的分野

这是DDD中最基础，也最需要仔细区分的两个概念。简单来说，实体具有唯一标识符，其相等性由ID决定，即使属性全部相同，两个ID不同的对象也不是同一个东西。值对象则没有概念上的标识，其相等性由所有属性值共同决定，且通常不可变。

在C++中，我们可以用非常直观的方式来实现它们：

• 实体：通常用一个具有唯一id成员（例如std::string或int）的类来表示。这个id在对象构造时被赋予（可能由仓储生成），并在其整个生命期内保持不变。实体类可以拥有修改其内部状态（除ID外）的方法。

  class Order { private: OrderId id_; // 值对象，封装ID类型和校验 CustomerId customerId_; OrderStatus status_; Money totalAmount_; std::vector<OrderLine> orderLines_; // 值对象集合 // ... 其他属性 public: // 构造函数，必须初始化id_ explicit Order(const OrderId& id, const CustomerId& customerId); // 实体标识的获取 const OrderId& id() const { return id_; } // 领域行为：添加订单项 void addItem(const ProductId& productId, int quantity, const Money& unitPrice); // 领域行为：确认订单 void confirm(); // ... 其他领域方法 };

  注意：这里将OrderId和CustomerId也设计成了值对象，而不是简单的std::string。这被称为“内聚标识符”，它能将ID的格式校验、生成逻辑封装在自身，避免“原始类型偏执”，是DDD中的一项重要实践。

• 值对象：理想情况下，值对象应该是不可变的、值语义的。在C++中，我们可以通过以下方式实现：

  1. 将所有成员变量设为private和const，并通过构造函数一次性初始化。
  2. 不提供任何修改内部状态的公共方法（Setter）。
  3. 重载operator==和operator!=，基于所有成员变量实现相等性比较。
  4. 通常遵循值语义，可以考虑重载operator<以便用于std::map的键，或者提供哈希函数用于std::unordered_map。

  class Money { private: const long long amount_; // 以分为单位存储，避免浮点数精度问题 const std::string currency_; // 如"CNY", "USD" public: Money(long long amount, std::string currency) : amount_(amount), currency_(std::move(currency)) { if (currency_.empty()) throw std::invalid_argument("Currency cannot be empty"); } // 值对象的行为：返回新的值对象，而不是修改自身 Money add(const Money& other) const { if (currency_ != other.currency_) throw std::runtime_error("Currency mismatch"); return Money(amount_ + other.amount_, currency_); } // 相等性比较 bool operator==(const Money& other) const { return amount_ == other.amount_ && currency_ == other.currency_; } bool operator!=(const Money& other) const { return !(*this == other); } // 获取器 long long amount() const { return amount_; } const std::string& currency() const { return currency_; } };

  实操心得：对于简单的值对象，使用struct并将所有成员设为public也未尝不可，只要保证它们逻辑上不可变即可。但用class封装能更好地控制不变条件（Invariant），比如在Money的构造函数中校验货币代码是否合法。

2.2 聚合与聚合根：一致性边界的守护者

聚合是DDD中最关键的模式之一，它定义了一组关联对象的边界，聚合根是这个聚合的“看门人”。外部对象只能持有对聚合根的引用，所有对聚合内部对象的修改，都必须通过聚合根进行。这保证了聚合作为一个整体的一致性。

在我们的订单系统中，Order（订单）自然是一个聚合根。OrderLine（订单项）是它的内部实体（注意，这里OrderLine可能是一个实体，因为它在一个订单内有自己的唯一标识，如lineNumber，但它的生命周期完全由Order管理）。

class Order { private: OrderId id_; // ... 其他属性 std::vector<std::unique_ptr<OrderLine>> orderLines_; // 使用智能指针管理生命周期 // 内部查找OrderLine的私有方法 OrderLine* findOrderLine(const ProductId& productId); public: // 添加订单项：聚合根上的方法 void addItem(const ProductId& productId, int quantity, const Money& unitPrice) { // 1. 检查业务规则（如商品是否可售） // 2. 查找是否已存在相同产品的订单项 if (auto* existingLine = findOrderLine(productId)) { existingLine->increaseQuantity(quantity); // 修改内部实体 } else { auto newLine = std::make_unique<OrderLine>(generateNextLineNumber(), productId, quantity, unitPrice); // 3. 维护聚合内的一致性（如重新计算订单总额） totalAmount_ = totalAmount_.add(newLine->subTotal()); orderLines_.push_back(std::move(newLine)); } // 4. 可能触发领域事件（如OrderItemAddedEvent） } // 移除订单项 void removeItem(const ProductId& productId); };

关键设计点：orderLines_使用std::unique_ptr管理。这意味着Order聚合完全掌控了OrderLine的生命周期。当Order被删除或从仓储中加载时，其关联的所有OrderLine也随之被处理。这完美体现了聚合的生命周期一致性。

2.3 仓储与工厂：领域与持久化的桥梁

仓储（Repository）的职责是模拟一个内存中的对象集合，用于存取聚合根。它抽象了底层的数据持久化技术（可能是SQL数据库、NoSQL或文件系统）。

在C++中，我们通常将仓储定义为接口（抽象基类），以便于测试和切换实现。

// 仓储接口位于领域层 class OrderRepository { public: virtual ~OrderRepository() = default; // 根据ID查找聚合根 virtual std::optional<std::unique_ptr<Order>> findById(const OrderId& id) = 0; // 保存或更新聚合根 virtual void save(Order* order) = 0; // 根据其他条件查询（返回多个） virtual std::vector<std::unique_ptr<Order>> findByCustomerId(const CustomerId& customerId) = 0; // 删除聚合根 virtual void deleteById(const OrderId& id) = 0; };

工厂（Factory）模式用于封装复杂聚合的创建逻辑。当创建一个Order需要执行复杂的初始化逻辑（如生成初始状态、关联默认值对象）时，可以提供一个OrderFactory类。

class OrderFactory { public: // 静态工厂方法 static std::unique_ptr<Order> createNewOrder(const CustomerId& customerId, const ShippingAddress& address) { auto orderId = OrderId::generate(); // ID生成策略 auto order = std::make_unique<Order>(orderId, customerId); order->setShippingAddress(address); order->setStatus(OrderStatus::PENDING); // ... 其他初始化 return order; } // 也可以从数据库数据重建订单（供仓储实现使用） static std::unique_ptr<Order> reconstitute(const OrderData& data); };

注意：是否需要一个独立的Factory类，取决于对象创建的复杂度。简单的new Order(...)如果足够清晰，则无需过度设计。

3. 领域模型深度解析：订单聚合的充血模型设计

有了核心概念的基础，我们来深入设计订单聚合的内部。DDD鼓励使用“充血模型”，即领域对象不仅包含数据，还包含与其数据紧密相关的业务逻辑。这与传统的“贫血模型”（仅有getter/setter）形成鲜明对比。

3.1 订单状态与状态模式

订单的生命周期通常由一系列状态定义，如待支付、已支付、已发货、已完成、已取消。状态之间的转换有严格的业务规则。我们可以使用枚举类，并在聚合根内部封装状态转换逻辑。

// 值对象：订单状态 enum class OrderStatus { PENDING, // 待确认 CONFIRMED, // 已确认 PAID, // 已支付 SHIPPED, // 已发货 DELIVERED, // 已送达 CANCELLED, // 已取消 RETURNED // 已退货 }; class Order { private: OrderStatus status_; public: void confirm() { if (status_ != OrderStatus::PENDING) { throw std::domain_error("Only pending orders can be confirmed."); } // 可能触发库存预占等检查 status_ = OrderStatus::CONFIRMED; // 记录领域事件：OrderConfirmedEvent domainEvents_.push_back(std::make_unique<OrderConfirmedEvent>(id_, customerId_)); } void cancel() { if (status_ == OrderStatus::SHIPPED || status_ == OrderStatus::DELIVERED) { throw std::domain_error("Shipped or delivered orders cannot be cancelled directly."); } if (status_ == OrderStatus::CANCELLED) { return; // 幂等处理 } status_ = OrderStatus::CANCELLED; // 触发库存释放、退款等后续流程（通过领域事件） domainEvents_.push_back(std::make_unique<OrderCancelledEvent>(id_, customerId_)); } // ... 其他状态转换方法 };

对于更复杂的状态机，可以考虑引入专门的状态类（State Pattern），但大多数情况下，像上面这样在聚合根方法中进行守卫条件判断和状态转移，已经足够清晰。

3.2 不变条件与业务规则校验

聚合根的一个重要职责是维持其内部以及聚合内部各对象之间的不变条件。这些是必须始终为真的业务规则。校验应该发生在状态改变的地方。

void Order::addItem(const ProductId& productId, int quantity, const Money& unitPrice) { // 守卫条件1：订单状态是否允许修改？ if (status_ != OrderStatus::PENDING && status_ != OrderStatus::CONFIRMED) { throw std::domain_error("Cannot add items to an order that is already being processed."); } // 守卫条件2：数量是否有效？ if (quantity <= 0) { throw std::invalid_argument("Item quantity must be positive."); } // 守卫条件3：单价是否有效？（假设有一个最小单价规则） if (unitPrice.amount() < MIN_UNIT_PRICE) { throw std::domain_error("Unit price is below minimum allowed."); } // 业务规则：检查库存？—— 注意，这通常是一个涉及外部服务的操作。 // 在DDD中，库存检查可能通过一个领域服务（Domain Service）来完成， // 或者，在添加商品时，我们假设前端/应用层已经做过校验。 // 更严谨的做法是，在`confirm()`订单时，通过领域服务进行库存预占。 // ... 实际的添加逻辑 }

常见问题：在哪里进行数据有效性校验（如非空、格式）？建议在值对象（如OrderId,Money）的构造函数中进行最基础的校验。在聚合根方法中，则专注于业务规则的校验。这样分层校验，职责清晰。

3.3 领域事件的设计与发布

领域事件是聚合内发生的重要事情的事实记录。它们用于解耦聚合之间的直接依赖，实现最终一致性。例如，OrderConfirmedEvent（订单确认事件）可能触发“发送确认邮件”、“预占库存”等后续流程。

在C++中实现一个简单的领域事件机制：

// 基类：领域事件 class DomainEvent { public: virtual ~DomainEvent() = default; virtual std::string eventType() const = 0; virtual std::chrono::system_clock::time_point occurredOn() const = 0; }; // 具体事件 class OrderConfirmedEvent : public DomainEvent { private: OrderId orderId_; CustomerId customerId_; std::chrono::system_clock::time_point occurredOn_; public: OrderConfirmedEvent(OrderId orderId, CustomerId customerId) : orderId_(std::move(orderId)), customerId_(std::move(customerId)), occurredOn_(std::chrono::system_clock::now()) {} std::string eventType() const override { return "OrderConfirmedEvent"; } std::chrono::system_clock::time_point occurredOn() const override { return occurredOn_; } const OrderId& orderId() const { return orderId_; } const CustomerId& customerId() const { return customerId_; } }; // 在聚合根中收集事件 class Order { private: std::vector<std::unique_ptr<DomainEvent>> domainEvents_; public: void confirm() { // ... 状态转换逻辑 domainEvents_.push_back(std::make_unique<OrderConfirmedEvent>(id_, customerId_)); } // 提取并清空事件列表（通常在仓储保存聚合后被调用） std::vector<std::unique_ptr<DomainEvent>> releaseDomainEvents() { std::vector<std::unique_ptr<DomainEvent>> events; std::swap(events, domainEvents_); return events; } };

应用服务（Application Service）在调用仓储save订单后，会获取这些事件，并将其发布到事件总线（Event Bus）或消息队列，由相应的事件处理器（EventHandler）进行异步处理。

4. 基础设施与分层架构实现

领域模型是核心，但它需要运行在一个完整的架构中。我们采用经典的分层架构：用户接口层、应用层、领域层、基础设施层。

4.1 项目结构与依赖关系

一个清晰的C++项目结构对于维护DDD代码至关重要。建议按物理目录进行分层：

order_system/ ├── CMakeLists.txt ├── application/ # 应用层 │ ├── services/ # 应用服务 │ │ └── OrderApplicationService.h/.cpp │ └── dtos/ # 数据传输对象 (DTO) ├── domain/ # 领域层 (核心) │ ├── models/ # 聚合、实体、值对象 │ │ ├── Order.h/.cpp │ │ ├── OrderId.h/.cpp │ │ ├── Money.h/.cpp │ │ └── ... │ ├── repositories/ # 仓储接口 │ │ └── OrderRepository.h │ ├── services/ # 领域服务接口 │ │ └── InventoryService.h │ └── events/ # 领域事件 │ └── OrderConfirmedEvent.h/.cpp ├── infrastructure/ # 基础设施层 │ ├── persistence/ # 持久化实现 │ │ ├── sql/ # SQL实现 │ │ │ ├── SqlOrderRepository.h/.cpp │ │ │ └── DbConnection.h │ │ └── in_memory/ # 内存实现（用于测试） │ │ └── InMemoryOrderRepository.h/.cpp │ ├── messaging/ # 消息/事件总线实现 │ └── logging/ └── interfaces/ # 用户接口层 ├── rest/ # REST API 控制器 │ └── OrderController.h/.cpp └── cli/ # 命令行接口

依赖规则：内层不依赖外层。领域层是核心，它不依赖任何其他层。应用层依赖领域层。基础设施层和用户接口层依赖应用层和领域层。在C++中，这主要通过#include头文件的方向和构建系统的依赖配置来保证。

4.2 仓储的C++实现策略

仓储接口在领域层，实现在基础设施层。以SQLite为例，实现SqlOrderRepository：

// infrastructure/persistence/sql/SqlOrderRepository.h #include <memory> #include <sqlite3.h> #include "domain/repositories/OrderRepository.h" #include "domain/models/Order.h" class SqlOrderRepository : public OrderRepository { private: std::shared_ptr<sqlite3> dbConnection_; // 使用shared_ptr管理连接，自定义删除器 std::unique_ptr<Order> mapRowToOrder(sqlite3_stmt* stmt); // 映射数据库行到领域对象 public: explicit SqlOrderRepository(const std::string& dbPath); ~SqlOrderRepository() override = default; std::optional<std::unique_ptr<Order>> findById(const OrderId& id) override; void save(Order* order) override; // ... 其他方法实现 };

实现save方法的关键点：

1. 保存聚合根：将Order对象的属性（ID、状态、客户ID等）插入或更新到orders表。
2. 保存聚合内的集合：由于Order包含OrderLine的集合，需要先删除该订单下所有旧的订单项（DELETE FROM order_lines WHERE order_id = ?），再插入当前的所有订单项。这保证了聚合作为一个整体被持久化。
3. 处理领域事件：在save操作成功后，通常需要调用order->releaseDomainEvents()获取事件并发布。这部分逻辑可以放在应用服务中，也可以由仓储触发一个回调。

实操心得：对象-关系映射（ORM）的选择：在C++中，没有像Hibernate或Entity Framework那样全功能的ORM。我们可以选择：

• 纯SQL + 手动映射：如上面示例，控制力最强，但代码繁琐。
• 使用轻量级ORM库：如SQLiteCpp、sqlite_orm或SOCI。它们能简化CRUD，但复杂的聚合嵌套映射仍需自己处理。
• 自定义简单的映射层：针对每个聚合根编写专门的DataMapper类，负责对象与数据库表之间的转换。这往往是大型C++项目折中的选择。

4.3 应用服务：协调用例

应用层服务非常“薄”，它不包含业务逻辑，只负责：

1. 从仓储获取聚合。
2. 调用领域对象的方法执行业务操作。
3. 调用仓储保存聚合。
4. 发布领域事件。
5. 处理事务（如果需要）。

// application/services/OrderApplicationService.h #include <memory> #include "domain/repositories/OrderRepository.h" #include "infrastructure/messaging/EventPublisher.h" class OrderApplicationService { private: std::unique_ptr<OrderRepository> orderRepository_; std::unique_ptr<EventPublisher> eventPublisher_; public: OrderApplicationService(std::unique_ptr<OrderRepository> repo, std::unique_ptr<EventPublisher> publisher) : orderRepository_(std::move(repo)), eventPublisher_(std::move(publisher)) {} void confirmOrder(const std::string& orderIdStr) { // 1. 参数转换与基础校验（应用层校验） OrderId orderId(orderIdStr); // 可能抛出异常（如格式错误） // 2. 获取领域对象 auto orderOpt = orderRepository_->findById(orderId); if (!orderOpt) { throw std::runtime_error("Order not found."); } auto& order = *orderOpt; // 3. 调用领域行为 order->confirm(); // 核心业务逻辑在这里 // 4. 持久化 orderRepository_->save(order.get()); // 5. 发布事件 auto events = order->releaseDomainEvents(); for (auto& event : events) { eventPublisher_->publish(std::move(event)); } } // ... 其他用例：createOrder, cancelOrder, addItemToOrder等 };

事务边界：一个应用服务方法通常对应一个用例，也对应一个事务边界。在上面的例子中，confirmOrder方法内的findById、order->confirm()、save和publish应该在一个数据库事务中。这可以通过在基础设施层实现一个UnitOfWork模式，或者在应用服务方法开始和结束时手动控制事务来实现。

5. 测试策略与常见问题排查

没有测试的DDD项目就像没有图纸的建筑。测试能确保我们的领域模型行为符合预期，并且架构是松耦合的。

5.1 领域层的单元测试

领域层是纯业务逻辑，不依赖外部，最适合做单元测试。使用Google Test或Catch2等框架。

// tests/domain/OrderTest.cpp TEST(OrderTest, ShouldAddItemAndCalculateTotal) { // 准备 OrderId orderId("order-123"); CustomerId customerId("cust-456"); Order order(orderId, customerId); ProductId productId("prod-789"); Money unitPrice(10000, "CNY"); // 100.00元 // 执行 order.addItem(productId, 2, unitPrice); // 验证 // 验证订单总额是否正确 ASSERT_EQ(order.totalAmount(), Money(20000, "CNY")); // 验证订单项数量 // 可以通过一个只读的getter获取订单项信息（注意：返回const引用或拷贝，避免暴露内部可变性） } TEST(OrderTest, ShouldNotAddItemToCancelledOrder) { Order order(...); order.cancel(); // 验证调用addItem会抛出特定异常 EXPECT_THROW(order.addItem(...), std::domain_error); }

测试重点：

• 业务规则：状态转换是否正确？不变条件是否被维护？
• 领域事件：执行某个操作后，是否正确生成了对应的事件？
• 值对象行为：Money的加减乘除计算是否正确？相等性判断是否准确？

5.2 仓储与集成测试

仓储的实现需要与真实的数据库交互，属于集成测试范畴。我们需要一个测试数据库（如内存SQLite），并在每个测试用例前后进行数据清理。

// tests/infrastructure/SqlOrderRepositoryTest.cpp class SqlOrderRepositoryTest : public ::testing::Test { protected: void SetUp() override { // 创建内存数据库连接 // 执行建表SQL } void TearDown() override { // 关闭连接 } std::unique_ptr<OrderRepository> repository_; }; TEST_F(SqlOrderRepositoryTest, ShouldSaveAndRetrieveOrder) { // 创建并保存一个订单 auto order = OrderFactory::createNewOrder(...); order->addItem(...); repository_->save(order.get()); // 通过ID查找 auto retrievedOrderOpt = repository_->findById(order->id()); ASSERT_TRUE(retrievedOrderOpt.has_value()); auto& retrievedOrder = *retrievedOrderOpt; // 验证找回的订单状态、总额等与原始订单一致 ASSERT_EQ(retrievedOrder->totalAmount(), order->totalAmount()); // 验证订单项也被正确保存和加载 }

5.3 常见问题与排查技巧

在实践C++ DDD的过程中，我踩过不少坑，这里总结几个典型问题：

1. 循环依赖与头文件包含：

   • 问题：领域对象Order需要知道OrderRepository接口，而OrderRepository又需要返回Order对象，容易造成循环包含。
   • 解决：使用前向声明（Forward Declaration）。在Order.h中，只包含必要的值对象头文件。对于OrderRepository，仅作前向声明class OrderRepository;。在Order.cpp中再包含OrderRepository.h。仓储接口头文件使用#include “domain/models/Order.h”。

2. 聚合根内部集合的暴露问题：

   • 问题：为了方便测试或UI展示，为orderLines_提供了一个getOrderLines()方法，返回std::vector<OrderLine>&，这破坏了封装性，外部代码可能直接修改集合。
   • 解决：
     • 返回const引用：const std::vector<std::unique_ptr<OrderLine>>& getOrderLines() const;。这能防止外部修改，但外部仍能看到内部对象的指针。
     • 返回一个只读的视图或拷贝：例如返回std::vector<OrderLineSnapshot>（一个只包含数据的简单结构体）。这是最安全的方式，但可能有性能开销。
     • 最佳实践：除非必要，否则不要暴露内部集合。UI展示所需的数据，应由应用层服务组装专门的DTO（Data Transfer Object）来提供。

3. 领域事件的内存管理：

   • 问题：使用std::unique_ptr<DomainEvent>存储事件，在releaseDomainEvents()时转移所有权。事件发布后，谁来删除事件对象？
   • 解决：事件发布器（EventPublisher）在将事件传递给所有处理器后，负责清理事件对象。可以使用std::shared_ptr，但通常事件是“发射后不管”的，unique_ptr更合适。确保发布器的实现正确处理了事件对象的生命周期。

4. 值对象的序列化/反序列化：

   • 问题：将Money这样的值对象存入数据库或JSON，需要将其“扁平化”为基本类型（如amount和currency字符串）。
   • 解决：在值对象内部或为其编写专用的辅助类，提供toJson(),fromJson(),toDatabaseRow()等方法。在仓储的实现中调用这些方法。避免在领域模型外部（如应用层）直接操作值对象的内部数据。

5. 性能考量：

   • 问题：每次加载订单聚合，都要加载其所有订单项，如果订单项很多（比如上万条），会影响性能。
   • 解决：DDD强调通过聚合根访问数据，这有时与数据库查询优化冲突。一种折中方案是：
     • 延迟加载：在仓储实现中，可以为聚合根提供一个“轻量级”版本，不立即加载所有子集合。当真正需要访问orderLines_时，再触发加载。但这会使得仓储实现复杂化。
     • 查询分离：遵循CQRS（命令查询职责分离）思想。对于写操作（命令），严格通过聚合根进行。对于复杂的读操作（查询），可以绕过领域层，直接使用基础设施层的高效查询（如复杂的SQL JOIN）构建专门的、只读的视图模型（View Model）或DTO，直接提供给展示层。这是应对复杂查询性能问题的标准DDD/CQRS模式。

将DDD应用于C++项目是一次富有挑战但回报丰厚的旅程。它迫使你从纷繁复杂的技术细节中抽离出来，首先聚焦于业务语言和核心逻辑。一开始，你可能会觉得为Money或OrderId创建一个完整的类有些“过度设计”，但随着项目演进，你会发现这种“显式建模”带来的代码清晰度、类型安全性和可维护性是无可替代的。最重要的是，这套方法论让C++程序员也能以一种结构化的、面向领域的方式，去构建那些真正复杂、核心的业务系统。