关于DDD的一些话
1、Domian层的价值就在于，它为我们提供了一种内聚业务逻辑、显性化表达业务语义的地方。
避免散淡式的代码
Knowledge Rich Design (知识丰富的设计）
2、我更愿意把Domain层设计成开放的，这种开放性不仅体现在CQRS的时候，App可以绕过Domain层直达Infrastructure；也体现在当你的团队实在hold不住DDD的时候，可以选择退化到老的三层架构。
3、“先把App做厚，再把App做薄”
先可以把业务逻辑都写到App里面，在写的过程中，我们会发现有一些业务逻辑，不仅仅是过程式的代码，它也是领域知识（Domain knowledge），应该被更加清晰、更加内聚的表达出来，那么我们就可以把这段代码沉淀为领域能力。
4、落地DDD工程的开发范式
-
梳理业务：梳理业务流程，挖掘领域概念，形成统一语言。
-
战略设计：划分领域边界，建立限界上下文。
-
战术设计：寻找实体，建立关系，形成领域模型。
-
API设计：根据用户故事，输出服务功能API。
-
做厚App：根据API功能要求，在App层编写业务过程代码。
-
做薄App：以领域模型为基础，优化过程代码，沉淀领域能力和领域知识，让业务语义显性化，做到Knowledge Rich Design (知识丰富的设计）。
-
技术细节：完善技术细节代码，比如API的暴露方式（RPC 或者 Restful），数据的存储方式（关系数据库 或者 NoSQL），ORM框架的选用（MyBatis 或者 JPA)等等。
5、"Open to extend，Close to change"可以说是我们工程师的梦想，没有人愿意修改原来已经work的东西，因为修改就意味着要重新测试，就以为着可能引入新的bug，就以为着头发变少...... 大部分的设计模式都是为了OCP这个目标在努力。
6、应用架构的核心使命就是要分离业务逻辑和技术细节。让核心业务逻辑可以反映领域模型和领域应用，可以复用，可以很容易被看懂。让技术细节在辅助实现业务功能的同时，可以被替换。
最后我们发现，应用架构的道就是：“让上帝的归上帝，凯撒的归凯撒。”
7、复杂业务代码要怎么写：即自上而下的结构化分解+自下而上的面向对象分析
8、架构师永远要在Reuse高耦合和Repeat低耦合之间做一个权衡。这种权衡就是Reuse和Repeat的中庸之道。
9、
-
失血模型：模型只是数据接口，没有任何的方法（能力）。
-
贫血模型：模型包含了一些原子能力。
-
充血模型：模型包含了除了持久化之外的所有能力。
-
胀血模型：模型无所不包。
10、所谓的clean code，就是尽量让每一个“逻辑盒子”都封装合理——隐藏该隐藏的，暴露该暴露的，让系统呈现出一个清晰、可理解的结构，而不至于失控。
把系统中的重要领域概念挖掘出来，封装成可以复用的类，把业务语义显性化的表达出来，这种方式可以极大的增加系统的可理解性。
11、
领域模型建模的关键是看模型能否显性化、清晰的表达业务语义，扩展性是其次。
数据模型建模的决策因素主要是扩展性、性能等非功能属性，无需过分考虑业务语义的表征能力。
正确的做法应该是有意识的把这两个模型区别开来，分别设计，因为他们建模的目标会有所不同。如下图所示，数据模型负责的是数据存储，其要义是扩展性、灵活性、性能。而领域模型负责业务逻辑的实现，其要义是业务语义显性化的表达，以及充分利用OO的特性增加代码的业务表征能力。
