业务配置一定属于具体的业务模块，因为配置是用户控制某个具体的模块逻辑，所以配置尽量挂在模块下面是一个非常自然的做法 。
我的观点
业务配置一定属于具体的业务模块，因为配置是用户控制某个具体的模块逻辑，所以配置尽量挂在模块下面是一个非常自然的做法 。
3.2.5 其他优势
- 让业务，产品，在提需求的时候，就能够以系统能力的方式去思考 。
- 在有新需求时，产研可以方便的在能力树上找到需要改动的模块 。
- 测试的影响范围也很容易确定 。对修改友好，影响范围可控 。
- 让程序员天然的进行开闭原则，对新增开放，对修改改封闭 。
现实世界是一个模块化的，层次化的树状结构，所以业务系统就应该自然的通过模块化的树状结构来进行映射 。
MTDD正是基于此，通过一个可视化的能力树，这颗能力树作为实实在在，可以看得见的桥梁，来拉齐业务、产品和系统研发 。并最终做到让业务和产品，可以真正以产品能力搭建的视角来规划，设计系统模块和系统功能 。可以让系统架构人员自然而然的进行高内聚，低耦合的系统设计，可以让一线研发自然而然的进行模块化编程 。
模块树驱动设计闭环
文章插图
图片
4、MTDD实战4.1 MTDD战略层4.1.1 统一语言DDD中也有统一语言，或者叫做“通用语言（Ubiquitous Language ）”
当团队成员不能享用一个公共语言来讨论领域时，项目会面临严重的问题 。领域专家使用自己的行话，技术团队成员在设计中也用自己的语言讨论领域 。
代码可能是一个软件项目中最重要的产物，但每天用来讨论的术语却与代码中使用的术语脱节了 。即使是同一个人都需要使用不同的 语言来交谈和书写，所以要想完成对领域的深刻表达通常需要产生 一种临时形式，但这种形式不会出现在代码甚至是书写的内容中 。
在交流的过程中，需要做翻译才能让其他的人理解这些概念 。开发 人员可能会努力使用外行人的语言来解析一些设计模式，但这并一定都能成功奏效 。领域专家也可能会创建一种新的行话以努力表达 他们的这些想法 。在这个痛苦的交流过程中，这种类型的翻译并不能对知识的构建过程产生帮助 。
上面这段是话是摘自《领域驱动设计精简版 》
Eric Evans 早就意识到，需要在领域专家和研发之间共用一套通用语言，并且Eric Evans也做了大量的举例说明，来说明什么是通用语言，以及统一通用语言可以更好的服务于系统设计 。
MTDD更也是站在巨人的肩膀上，提供了一个方法论：让业务，产品，技术在系统设计之前，一起对照系统模块树来进行沟通；对于一个新功能，一起思考是在某个模块下新增模块，还是修改货扩展模块内部的逻辑；在对齐后，就可以进行开发了，并且研发有一定的范式开做开发，开发后，系统的模块树就能够自动可视化的呈现出来；业务和产品也可以通过可视化的方式进行验收；
4.1.2 按定制规范来做设计和开发上面说了在业务方、产品、技术在参照能力树根据需求并对齐需要开发的模块后，研发可以按照一定的范式做系统开发；这是因为我们提供了一套开发的SDK，以及SDK的使用文档，来帮助研发人员来进行基于能力树功能的开发 。系统功能开发完成后，相应的模块信息就可以自动在模块树页面上进行呈现 。当然想要在页面上进行呈现，需要有前端来支持 。
这个规范主要由几个主要的JAVA注解来实现：
