Skip to content

Latest commit

 

History

History
152 lines (108 loc) · 9.59 KB

ddd.sample.md

File metadata and controls

152 lines (108 loc) · 9.59 KB

Q1:定义

我们来定义一下 DDD 游戏的步骤,一共有 6 个步骤,步骤如下:

"""
第一步. 拆解场景。分析特定领域的所有商业活动,并将其拆解出每个场景。
第二步. 场景过程分析。选定一个场景,并使用 "{名词}已{动词}" 的形式描述过程中所有发生的事件,其中的名词是过程中的实体,其中的动词是实体相关的行为。
第三步. 针对场景建模。基于统一语言和拆解出的场景进行建模,以实现 DDD 设计与代码实现的双向绑定。
第四步. 持续建模。回到第一步,选择未完成的场景。你要重复第一到第四步,直到所有的场景完成。
第五步. 围绕模型生成子域。对模型进行分类,以划定不同的子域,需要列出所有的模型包含英语翻译。
第六步. API 生成。对于每一个子域,生成其对应的 RESTful API,并以表格的形式展现这些 API。
"""

需要注意的是,当我说 """ddd 第 {} 步: {}""" 则表示进行第几步的分析,如 """ddd 第一步: 博客系统""" 表示只对博客系统进行 DDD 第一步分析。我发的是 """ddd: {}""",则表示按 6 个步骤分析:

明白这个游戏怎么玩了吗?

ChatGPT:

是的,我明白了,这是一个通过 DDD(领域驱动设计)方法论进行软件开发的游戏,一共有 6 个步骤。第一步是拆解场景,将特定领域的商业活动拆解为多个场景。 第二步是针对一个场景进行过程分析,使用 "{名词}已{动词}" 的形式描述场景中所有事件。第三步是基于统一语言和拆解出的场景进行建模,实现 DDD 设计与代码实现的双向绑定。 第四步是持续建模,回到第一步选择未完成的场景,重复第一到第三步直到所有场景完成。第五步是围绕模型生成子域,对模型进行分类,以划定不同的子域。 第六步是生成每个子域对应的 RESTful API,并以表格的形式展现这些 API。

Q2: DDD 游戏分析一下在线商城

好的,让我们来进行 DDD 游戏的分析,以在线商城为例。

ddd 第一步:拆解场景

在线商城的场景可以分为以下几个:

用户注册和登录
商品展示和搜索
购物车管理
订单管理和支付
物流配送
售后服务

ddd 第二步:场景过程分析

下面是每个场景的过程分析:

用户注册和登录
    用户注册:用户填写注册信息,系统验证信息合法性,生成用户账户并保存。
    用户登录:用户输入账户名和密码,系统验证账户密码,登录成功后跳转到用户中心。

商品展示和搜索
    商品列表展示:系统从数据库中获取商品列表并展示,用户可以进行商品分类和排序。
    商品搜索:用户输入关键词进行商品搜索,系统根据关键词从数据库中获取商品列表并展示。

购物车管理
    加入购物车:用户在商品详情页点击“加入购物车”按钮,系统将商品信息添加到购物车中。
    查看购物车:用户在购物车页面可以查看已添加的商品列表,修改商品数量或删除商品。

订单管理和支付
    下单:用户在购物车页面点击“提交订单”按钮,系统生成订单并保存,同时减少商品库存。
    支付:用户选择支付方式并支付订单,系统验证支付状态并修改订单状态为“已支付”。

物流配送
    发货:系统根据订单信息生成发货单,安排快递公司发货。
    物流跟踪:用户可以查看物流公司提供的物流信息,跟踪订单状态。

售后服务
    申请退款/退货:用户可以提交退款/退货申请,系统验证订单状态并处理申请。
    售后咨询:用户可以在网站上咨询客服人员,获取售后服务。

ddd 第三步:针对场景建模

根据以上场景过程分析,可以建立以下领域模型:

用户模型:包含用户的基本信息、账户信息等。
商品模型:包含商品的基本信息、价格、库存等。
购物车模型:包含用户的购物车信息、商品数量、价格等。
订单模型:包含订单的基本信息、商品信息、收货地址、订单状态等。
物流模型:包含物流信息、快递公司信息等。
售后模型:包含退款/退货申请、售后咨询等信息。

ddd 第四步:持续建模

在持续建模过程中,我们会发现一些未完善的场景或者需要调整的模型,需要回到第一步重新分析场景,或者更新模型

Q3:继续 在线商城的 """ddd 第四步:持续建模"""

在第三步中,我们对在线商城进行了场景建模,对其领域内的实体、值对象、聚合等进行了定义。在第四步中,我们需要回到第一步,选择未完成的场景,继续进行领域建模,直到所有的场景完成。

未完成的场景可以包括以下几个方面:

  1. 订单管理:订单是在线商城最核心的业务之一,我们需要对订单的整个生命周期进行建模,包括订单创建、修改、支付、配送、退款等流程。订单的实体、值对象、聚合需要在场景建模中进行定义。
  2. 商品管理:在线商城中,商品是核心的交易物品,我们需要对商品的属性、分类、库存等进行建模。此外,还需要考虑到商品的上架、下架、促销等场景。
  3. 用户管理:用户是在线商城的重要角色,我们需要对用户的属性、角色、权限等进行建模。此外,还需要考虑到用户的注册、登录、退出、密码找回等场景。
  4. 支付管理:支付是在线商城的核心业务之一,我们需要对支付的整个流程进行建模,包括支付方式的选择、支付金额的计算、支付状态的维护等。
  5. 物流管理:物流是在线商城中与订单配送相关的业务,我们需要对物流的整个流程进行建模,包括物流信息的采集、订单状态的更新等。

在持续建模过程中,我们需要不断地与业务人员进行沟通,了解业务变化和新的需求,并将其反映到领域模型中。此外,还需要注意模型的内聚性和可扩展性,保证模型的清晰度和可维护性。

Q4: 继续 DDD 游戏 在线商城 的第五步和第六步

在完成持续建模后,我们可以根据领域模型的分类,围绕模型生成子域。在线商城中,可能包括以下几个子域:

  1. 商品子域:负责管理商品的相关业务,包括商品的添加、编辑、删除、查询等功能。
  2. 订单子域:负责管理订单的相关业务,包括订单的创建、支付、配送、退款等功能。
  3. 用户子域:负责管理用户的相关业务,包括用户的注册、登录、退出、密码找回等功能。
  4. 支付子域:负责管理支付的相关业务,包括支付方式的选择、支付金额的计算、支付状态的维护等功能。
  5. 物流子域:负责管理物流的相关业务,包括物流信息的采集、订单状态的更新等功能。

接下来,我们可以针对每个子域,生成其对应的 RESTful API,并以表格的形式展现这些 API。API 的设计需要符合领域模型的设计,并考虑到业务的实际需求和性能的优化。此外,还需要考虑到安全性和可扩展性等方面的问题。

以下是在线商城中可能涉及的一些 API 的设计示例:

商品子域:

API名称 请求方法 请求路径 请求体 响应体 描述
创建商品 POST /api/products 商品信息 创建的商品信息 创建一个新的商品
获取商品列表 GET /api/products 商品列表信息 获取所有的商品列表
获取单个商品信息 GET /api/products/{id} 单个商品信息 根据商品 ID 获取单个商品信息
更新商品信息 PUT /api/products/{id} 更新的商品信息 更新后的商品信息 根据商品 ID 更新商品信息
删除商品 DELETE /api/products/{id} 根据商品 ID 删除商品信息

订单子域:

API名称 请求方法 请求路径 请求体 响应体 描述
创建订单 POST /api/orders 订单信息 创建的订单信息 创建一个新的订单
获取订单列表 GET /api/orders 订单列表信息 获取所有的订单列表
获取单个订单信息 GET /api/orders/{id} 单个订单信息 根据订单 ID 获取单个订单信息
更新订单信息 PUT /api/orders/{id} 更新的订单信息 更新后的订单信息 根据订单 ID 更新订单信息
删除订单 DELETE /api/orders/{id} 根据订单 ID 删除订单信息

用户子域:

HTTP方法 URL 描述
GET /users/{user_id} 获取用户信息
PUT /users/{user_id} 更新用户信息

支付子域:

HTTP方法 URL 描述
POST /payments 创建支付订单

物流子域:

HTTP方法 URL 描述
POST /shipments 创建物流订单