DDDML文档的根结点下有什么
- 每个DDDML文档都必须遵循同样的Schema。 在所有需要归并到同一个限界上下文的不同DDDML文档中，除了文档根结点以及少数几个特殊的文档根结点的直接子结点（即/aggregates、/valueObjects、/enumObjects、/superObjects）之外，不允许重复出现路径相同的结点。比如，不允许在两个DDDML文档中都出现/aggregates/Car结点
aggregates结点
- 在实践中，一般会把每个聚合的定义都单独放在一个DDDML文件中，然后以聚合的名称为文件命名，但这不是必需的
valueObjects结点
- 可以在聚合的结点中定义和这个聚合联系紧密的值对象，比如在/aggregates/Car/valueObjects结点中定义和Car聚合联系紧密的值对象
enumObjects结点
- 可以认为枚举对象只是一种特殊的值对象。限界上下文内公共的枚举对象（Enum Object）可以像下面一样定义在/enumObjects结点下
typeDefinitions结点
- 在值对象中，还有一类作为一个限界上下文的领域基础类型来定义的值对象，它们一般会放在单独的文件里，定义在/typeDefinitions结点下。
configuration结点
- 在DDDML文档根结点下可能还有一个很重要的直接子结点/configuration，整个限界上下文的全局配置信息都保存在这个结点下。
名称空间
- DDDML要求在整个限界上下文内，所有对象（包括值对象、实体、服务、工厂、存储库等）都有一个独一无二的名字
- 当我们面向特定的领域开发一个应用时，需要建立一张词汇表，表上的每个词条（术语）都有且只有一个明确的定义
再谈PascalCase命名风格
推荐在DDDML文档中为对象命名时使用PascalCase的命名风格：
- 对于两个字母的首字母缩写词，应该两个字母都大写，比如“InOut”的缩写为“IO”。
- 超过两个字母的首字母缩写词，只应该将第一个字母大写，也就是说，我们应该使用“Html”而不是“HTML”。
关于模块
- 所有对象（类型）的名字在整个限界上下文中不应该发生冲突，因此，对生成代码来说，将DDDML中声明的模块映射为具体语言的“Namespace”——比如Java的package（包）或C#的namespace——不是必需的，这就让模块这个概念在DDDML中的地位进一步边缘化了。
