业务建模基础
业务建模首先是一个定义问题的方法, 其次才是解决问题的方法
业务建模的难点:
- 清晰地定义业务问题，并让所有干系人都接受你对业务问题的定义
- 在特定架构的约束下，将模型实现出来
领域驱动设计(Domain Driven Design, DDD)
领域模型
领域驱动设计是一种模型驱动的设计方法：通过领域模型（Domain Model）捕捉领域知识，使用领域模型构造更易维护的软件。
模型在领域驱动设计中，其实主要有三个用途：
- 通过模型反映软件实现（Implementation）的结构；
- 以模型为基础形成团队的统一语言（Ubiquitous Language）；
- 把模型作为精粹的知识，以用于传递。
领域模型对于业务系统是更好的选择: 构造一种专用的模型（领域模型），将相关的业务流程与功能转化成模型的行为，就能避免开发人员与业务方的认知差异
知识消化
在DDD 中，Eric Evans 提倡了一种叫做知识消化（Knowledge Crunching）的方法帮助我们去提炼领域模型
知识消化的五个步骤:
- 关联模型与软件实现；--> 将模型与代码统一在一起, 修改模型就是修改代码
- 基于模型提取统一语言；-->通过统一语言进行需求讨论
- 开发富含知识的模型；-->我理解这应该是建模的过程
- 精炼模型；-->类似需求澄清
- 头脑风暴与试验。-->持续完善
可以把“知识消化”这五步总结为“两关联一循环”：
- “两关联”即：模型与软件实现关联；统一语言与模型关联；
- “一循环”即：提炼知识的循环。
统一语言
统一语言: 统一语言特指根据领域模型构造的业务方与技术方都使用的共同语言。
- 统一语言是在使用中被确立的, 比如用户订阅极客时间的场景, 开发和业务以及其他的关联方对以下概念都达成了一致: "用户（User），指所有在极客时间注册过的人；订阅的专栏（Subscription），指用户付费过的专栏；用户可以订阅多个专栏；订阅"; 那就可以通过"作为一个用户（User），当我查阅购买过的专栏（Subscription）时，从而可以看到其中的教学内容。"这句话来描述需求了, 以上共同达成一致的概念, 就是统一语言
- 当且仅当，统一语言与领域模型关联，且多方认可并承认对统一语言的集体所有权时，统一语言才能成为真正的统一语言。
- 不能单纯使用模型作为统一语言, 因为模型隐藏了业务维度, 而且未提取的知识超出了模型的表达能力
怎么理解DDD
领域驱动设计实践背后的价值观:
- 领域驱动设计是一种模型驱动的设计方法：模型应处在核心；
- 两关联一循环：业务与技术围绕着模型的协同。
只要接纳这两条价值观的都可以声称自己采用了“领域驱动设计”。
领域驱动设计”至少可以指代一种建模法，一种协同工作方式和一种价值观。
作为建模法，领域驱动设计是迭代改进试错法
作为一种协同工作方式，领域驱动设计提供的思路是相当精彩的，所以也对行业产生了深远的影响，特别是统一语言
作为价值观来讲，则过于宽泛了
就我总结, DDD就是提倡通过知识消化的方式来提炼领域模型, 以领域模型为核心来构造更易维护的软件; 统一语言与提炼知识的循环作为一种更为 平衡的权责关系，促进了业务方与技术方更好的协作