DDDML
- DDDML的核心是一个文档对象模型（DOM），DDDML文档可以使用YAML、JSON或其他标记语言来编写。为方便读者阅读，本书展示的DDDML示例代码默认使用YAML这种对人类友好（相对于JSON具备更高的可读性）的标记语言来编写
为什么实现DDD 那么难
- 作为一种思想，领域模型好像太抽象，难以把握，它能不能更具象化一些？
- 怎么度量系统分析、领域建模的工作做到位了？能不能提供一些清晰的、严格的工作产出结果的标准？
- 能不能图形化展示领域模型？在领域建模之后马上给大家一个可以运行的、带UI的软件？
- 怎么保证代码忠实地反映了分析结果（领域模型）？毕竟，如果分析结果不能映射到实现代码中，那么分析有何意义？
- DDD能不能让各个层次的技术人员各司其职、各展所长？
- 将领域模型忠实地映射到实现代码需要的工作量如何？成本是不是我们团队可以承受的
搞定DDD的“锤子”在哪里
- 这个问题的终极答案可能是DSL。我们可以设计一门DDD的DSL，然后使用DSL描述领域分析和建模的结果——领域模型，并使用软件工具从DSL文档生成与领域模型存在映射关系的代码。
需要什么样的DSL
- 我们想要一个DSL，它能够描述DDD风格的领域模型。
- 这个DSL允许我们在一个地方集中记录和展示领域模型中的关键元素。
- 这个DSL应该能在概念层面描述领域模型，也允许我们在其中添加领域模型在实现层面需要的细节。
- 我们希望它能够支持代码生成工具以产生与领域模型之间具备亲密映射关系的软件代码。
- 我们希望软件的文档——包括使用Swagger/OpenAPI[1]、RAML描述的RESTful API文档，定义数据库Schema的DDL代码，领域模型中关键状态的状态机图等——都尽可能自动化地产生。
- 我们希望生成所谓的Client SDK，我们甚至希望能直接生成有UI的客户端应用，至少生成一些程序员在实现客户端应用的UI/UE（用户体验）时可以使用的脚手架代码……
DDDML的词汇表
-
DDDML DOM
- 正如DDD的领域模型其实是一个“思想”，DDDML的灵魂并不是以某种标记语言编写的文档，而是一个可以使用标记语言来表述的“思想”，即一组抽象的数据结构。 DDDML的核心，是一个我们称为DDDML文档对象模型（Document Object Model，DOM）的树结构。
-
借鉴自JSON的概念
- 如前所述，我们要求DDDML DOM必须可以使用JSON来表述，所以在讨论DDDML规范的时候，所使用的很多概念与JSON定义的同名概念具有相同的含义。比如，当我们提到string、number、integer、true、false、null、value等时，它们与JSON中的同名概念所指一致
-
结点
- 既然DDDML DOM是一个树结构，那么我们将这个结构中的元素称为结点（Node）就是很自然的事情了。 为了选取结点
-
Map
- JSON的Object是一个无序的名/值对的集合。在DDDML DOM中，我们把在概念上等同于“JSON的Object”的结点的类型称为Map
-
Object
- 在DDDML DOM中，当我们说一个值的类型是Object的时候，其实是说这个值的类型可以是string、number、boolean、Map、List等。可以认为Object是所有类型的基类型
-
List
- 我们都知道，JSON的Array是一个有序的值的集合。在DDDML DOM中，我们把在概念上等同于“JSON的Array”的结点的类型称为List（列表）
