统一语言建模
事件风暴
持续对代码职责维护
什么时候知道软件变化？
需求改的时候
有哪些对象？对象之间的关系
什么时候代码折分？拆分成类、领域、还是微服务？
领域层：充血模型
需求分析 -> 领域建模 -> 设计编码
原文分析法、事件风暴、四色建模法
架构师需要理解：业务规划、业务流程、业务痛点
统一语言建模
在第一次开发和后续维护的过程中不断的学习和理解业务需求
沟通能力？
沟通不畅的根本原因：语言不通，不同行业专业术语不一样，用客户的语言和他沟通
客户是一个群体，有一些问题对业务了解不多，但是有一些客户对业务很精通，我们需要从客户群体中找到精通业务的人（业务领域专家）
业务架构师需要同需求分析师、产品直接和客户沟通业务需求，理解业务
业务架构师从更宏观的角度理解业务，同时要评估技术可行性，提供可靠的技术方案
需求分析师从更细节的角度理解业务
事件风暴（Event Storming）
头脑风暴，是一个会议，群策群力
会议人员包括：开发人员和领域专家
以完成领域模型为目标，以探讨领域事件开始，从前往后依次梳理，以确保领域中所有事件能覆盖
识别
- 识别模型中可能的聚合及其聚合根
- 将模型分配到各个限界上下文中，构建上下文地图
领域事件：即领域中发生的事实（fact）
事实 是指已经发生过的事件，发生在过去，不会发生改变，重要的（需要记录下来的）
事件风暴 关注对象之间的关系，要做什么样的设计
用户故事 关注不同角色的目标，要做什么事
一般事件风暴，再 用户故事
问题域、子域与限界上下文
主题域 核心功能
支撑域