用户故事到通用语言
什么是用户故事？
在软件开发中，用户故事是一种对软件系统特性的非正式的自然语言描述，是敏捷软件开发中从终端用户的角度对软件系统特性进行捕捉的一种方式。用户故事描述了不 同类型的用户需要什么以及为什么需要，它可以帮助我们创建需求的简单描述。
用户故事的构建一般来说有三个环节
- 简单描述用户需求
- 围绕简单描述进行讨论
- 明确如何验证
分别对应用户故事的三个元素，也就是3C：Card(卡片)、Conversation(谈话)、Confirmation(验证)
Card(卡片)
“卡片”就是指对用户故事的简述（传统上人们通过便利贴在白板上构建用户故事），一个好的用户故事卡片包括三个要素：
- 谁：谁需要这个功能；
- 需要什么：想通过系统完成什么事情；
- 为什么：为什么需要这个功能，这个功能带来什么样的价值。
Conversation(谈话)
谈话是指用户、领域专家、产品经理、研发之间围绕用户故事进行的讨论，谈话是明确需求细节的必要环节。可以用文字对谈话进行简要记录，此外，也可以基于图形或 其他工具进行讨论。
Confirmation(验证)
验证代表了验收测试，描述了客户或者产品owner怎样确定用户故事已经被实现，且能够满足需求
领域划分
领域划分是以分离关注点为原则对问题空间的划分 子域是领域中某个方面的问题和解决它所涉及的一切
划分方法
- 基于故事分解的领域划分
根据用户故事，分离关注点。基于领域划分进行分工协作而非基于需求。普遍情况下基于需求进行分工，但是 这种方式会导致领域划分冲突、单个协作者关注点增加等问题。
子域类型
- 核心域：整个项目的核心价值所在
- 通用子域：不是核心域，但是经常会提供给其他域使用
- 支撑子域：不属于上述两个域
限界上下文
是在解决方案空间对模型的分解单位，划分子域的边界所在。
为什么需要限界上下文？ 自然语言具有模糊性，在不同的环境下意义不一样，同一个事物面向不同场景有不同模型。如果不划分边界，会使模型变得大而臃肿。
限界上下文是分工的单位。理想情况下，子域和限界上下文是一一对应的。
如何划分限界上下文？
- Domain Storytelling（领域故事陈述法）
- Event Storming （事件风暴法）
- 基于子域概念提取
微服务就是限界上下文的一种实现方式。
上下文映射
是指限界上下文之间的映射关系。也可以说是描述团队之间的协作关系以及上下文之间的集成关系。
更直白的说，一个上下文是否依赖另一个上下文。如果有依赖，被依赖的上下文如何提供自己的服务。
分层架构
传统MVC分层，会在业务处理Service中冗余大量代码，并且，包含数据是强耦合关系，不利于分层处理。
DDD经典四层架构
- 接口层(Adapter 适配层): 类似controller层
- 应用层(Application): 类似以前service实现
- 领域层(Domain): 数据实体定义
- 基础设施层(infrastructure): 数据库操作部分
