领域驱动设计到底在讲什么？

极客时间《如何落地业务建模》学习笔记，题图来自网络

01｜领域驱动设计到底在讲什么？

看了这篇专栏，感觉业务建模或者说领域驱动设计离我远了一点，虽然我也需要去捕捉领域知识。

套用专栏中的说法，在能力评估的过程中，构造一种评估模型，将评估相关的流程和功能转化成模型的行为，从而与业务方同意认知。

业务方和技术方使用统一语言，来描述、讨论需求，从中凝练知识形成领域模型，用领域模型驱动业务开发实现，同时从领域模型中提取出统一语言。

这里的领域模型似乎是“聚合”了分析模型和设计模型？

两关联一循环的提法挺好的，但是示意图似乎有些不够明确，我觉的在“分析模型参与需求，设计模型关联实现”的那副图中，把其中的分析模型和设计模型合并为“领域模型”也许能够更好的表达知识吧唧嘴。

对于思考题，业务方需要通过统一语言和技术方进行沟通，进而才能通过修改模型，进而修改代码，影响业务实现。

其实我觉得，如果业务方有足够的技术背景，而模型的修改又相对简单，那么也许可以跳过统一语言步骤，而技术方只要明白业务方为什么修改了模型，也能完成沟通。

当然，在有统一语言的情况下，可以更好的沟通相关利益方，统一语言也能够更好的提炼模型中的领域知识。感觉上统一语言应该比领域模型更容易理解。

文中的代码示例，能够很清楚的表达贫血模型和充血模型的异同，但是和统一语言、领域模型又有什么关系呢？

问题来了，统一语言究竟是什么？

还有一个问题，领域驱动建模适合什么样的场景？