在领域驱动设计（DDD）中，系统划分是一个关键过程。在商城系统这样一个复杂的业务中，对系统进行正确的划分至关重要。DDD倡导的是根据不同的业务能力将系统分解为多个有界上下文（Bounded Contexts），每个有界上下文之间维持明确的边界，并尽可能地把模型和业务逻辑隔离。

1. 核心领域和有界上下文的划分

我们首先需要识别商城系统中的核心领域和次要领域。核心领域是企业竞争优势的集中体现，比如产品选择和订单处理。次要领域对业务重要但不是核心竞争优势，比如支付处理（通常依赖第三方服务）。

每个领域可以被定义为一个有界上下文，例如：

• 产品目录（Product Catalog）：管理产品信息，分类，产品规格和库存等。

• 购物车（Shopping Cart）：管理用户的选购商品，数量的增减，选择优惠等。

• 订单（Ordering）：处理订单的创建，确认，状态跟踪和历史记录。

• 支付（Payment）：管理支付交易，包括支付方式的选择，支付确认等。

• 物流（Logistics）：负责货物的配送，追踪和配送状态更新。

• 用户账户（User Account）：管理用户信息，权限和用户偏好设置。

• 营销（Marketing）：处理促销活动，优惠券，积分系统等。

• 客服（Customer Service）：提供用户咨询，反馈，投诉的处理。

2. 确定上下文间关系

每个有界上下文定义了自己的模型和边界，接下来需要确定这些上下文之间是如何交互的。DDD中常见的有界上下文关系包括伙伴关系(Partnership)、共享内核(Shared Kernel)、顾客－供应商(Customer-Supplier)和防腐层(Anti-corruption Layer)等。

比如，订单和支付上下文可能就是顾客－供应商关系。订单系统负责创建订单，并通知支付系统进行支付处理；而支付系统提供接口供订单系统调用。

3. 创建领域模型

对于每个有界上下文，创建其领域模型，包括定义实体、值对象、聚合和领域服务等。

• 在产品目录上下文，一个聚合根可能是Product，它可能包括SKU, Name, Description, Price 和 Inventory 等值对象。

• 在订单上下文，一个聚合根可能是Order，它可能关联OrderLineItems, ShippingAddress, BillingInformation等。

4. 实现和集成

确保每个有界上下文通过建立清晰的通信路径，如使用REST API或消息队列等方式进行集成，并且尽可能地保持它们的自主性和松耦合性。

5. 反复迭代

设计初期的上下文划分往往并不完美，一般会随着开发的进行和对业务深入理解的过程中不断精化。每个上下文的边界也可能随着需求的变化而调整。

6. 关注领域逻辑和技术实施分离

注意不要让技术实施细节干扰领域模型的纯粹性。应用程序层、领域层、基础设施层等应该保持清晰的分离，以提供灵活性和可维护性。

综上所述，DDD在构建商城系统的过程中充当了总体规划和设计的蓝图，促使开发团队和业务专家紧密合作，以确保软件解决方案与业务策略的一致性和系统的可扩展性。