1.从领域到子域
领域与子域是DDD中的抽象概念，刚接触时如果过分深究其含义，很容易被其迷惑，举个简单例子理解下：你公司是做电商的，那电商就是你公司的领域，但是如果你领导跟你说我们要搞电商系统，你知道咋做吗？显然有点蒙，为什么？范围太大，问题不明确。这时候我们要对电商这个领域进一步细化，比如电商分为订单、商品、物流模块，那订单、商品、物流就属于电商领域下的子域，依然抽象，但更具体了，也更容易进行方案实施了，子域依然可以进一步细分为子子域，直到你觉得够具体了，就可以进行下一步的战略设计了。领域到子域的细分只是为了更具体化我们面对的问题，更方便实施解决方案
2.从问题域到解决方案域
0.产品愿景，搞清楚自己的定位：产品顶层价值设计，所有参与人员要对产品的目标用户，核心价值，竞争优势等信息达成一致，保证产品演进过程中不至于偏离方向
1.业务场景分析：站在用户的视角，采用用户旅程进行用例和场景的分析，参与者应尽量遍历所有业务细节，充分发表意见
2.提取实体、值对象：行为分析会产生许多命令以及事件，我们要从中提取实体以及值对象
3.识别聚合根，建立聚合：我们根据聚合根的管理性质，从实体中找出聚合根，以此发散，找出所有与其关联紧密的实体与值对象，形成聚合，聚合是DDD中的逻辑概念，是业务最小边界
4.划分限界上下文：我们根据上下文语义将聚合归类，形成一个个限界上下文，限界上下文是DDD中的逻辑概念，是聚合之上的一层边界
4.一些名词解释：
通用语言：在事件风暴的过程中，通过团队交流达成共识的，能够简明、清晰、准确的描述业务含义和规则的语言就是通用语言，通用语言包含术语和场景，能够直接反映到代码中，借助于通用语言，业务需求可以被准确转换为代码设计，代码的可读性更好
实体与值对象：实体有一个唯一的ID，除非ID相等，否则即使其他属性值都一样，也属于不同实体对象。具有一定的生命周期，会在生命周期中发生改变，但无论怎么变化，其ID始终不变，始终是原来的对象。值对象只是一组数据的组合，没有唯一标识，只要两个值对象的这组数据都相等，那这两个值对象就相等。本质上，实体对应的是看得见摸得着的实实在在的业务对象，有一定的属性以及业务逻辑，值对象只是包含了一组描述性属性的集合体，其依附于实体并对实体起描述作用
聚合：表示一组业务上密切相关的实体和值对象，聚合定义了高内聚和单一职责的业务与代码边界，在代码实现中，一个聚合往往对应了一个package
聚合根：每个聚合都会对应一个聚合根，聚合根首先是个实体，其次它作为聚合的管理者，在聚合内部负责管理实体和值对象的生命周期，协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑
限界上下文：在设计好聚合后，我们会根据业务语义将一个或多个聚合归到一起，形成一个限界上下文，限界上下文是聚合之上的一层逻辑边界。它定义一个语义上的边界，保证在其中的通用语言语义的准确性和无二义性，定义了其中领域模型的适用范围，使团队成员明确什么可以在其中实现，什么不应该在其中实现。
5.准备开始战术设计
事件风暴后，我们已经提取出了业务涉及的所有实体、值对象、聚合根、实体间的关联关系，以及逻辑概念上的聚合、限界上下文。我们称这些内容为领域模型，是战略设计的成果