就好像第一次读effective java才意识到什么叫做代码质量；第一次接触到Domain Driven Design才开始认识什么是design。在之前的博客， 分享十二本经典电子书，涉及java, OO design, spring, hibernate,struts2, agile 中，有DDD书的下载。
Domain Driven Design基于一些简单，重要，务实的理念。下面根据自己的理解总结DDD的基本理论。
1. 深刻理解Domain知识
DDD强调基于domain进行设计。前提是深刻理解领域知识，需要持续学习。另一个相关的实践是，“统一的语言”（ubiquitous language）。领域专家所用的术语是准确的，那么程序员讨论domain相关的问题时，也应该使用这种术语。并且在写code的时候，也使用这种术语。这样做的好处是，可以自然地把domain的东西map到code里，保持code反应domain。
2. 分层
Layered Architecture
程序需要分层，这是个简单的道理, 但需要真正形成意识。
分别说说Domain Driven Design涉及的四个layer.
2.1 Infrastructure层
主要从技术上对上面的各层提供支持。比如传送消息，持久化。UI层也可以分出更基础的component作为infrastructure层
2.2 UI层
UI层的作用是显示信息以及解释用户的输入命令。重要的是UI层没有domain knowledge.
2.3 application层
application层的作用是描述产品的外部功能，它可以协调UI和Domain层的互动。application层应该很薄。它没有domain knowledge.
2.4 Domain层
Domain层是最重要的层。封装所有的业务逻辑。
DDD也从另一个角度分解软件。一个软件的组成部分（building block）包括association, entity, value object, service, module。其中比较强调的是entity, value object和service. service比较容易理解，通常它是无状态的。它可以存在于application层，domain层或者infrastructure层。比较不容易区分的是entity和value object. entity强调的是它的id，而不是属性。强调它生命周期的继续性和同一性(continuity and identity), 而value object是用来“描述”entity的。value object在很多时候适合是immutable的。这里需要注意的是，如果你会使用hibernate,你会知道hibernate里的value object通常不能reference多个entity，换句话说，能reference多个entity的，通常就是entity. 而在DDD的理论中，"路线"是一个value object。而它可以reference连接"路线"的city(entity)和高速公路(entity)。
3. Domain Object生命周期
DDD的一个重要理论是关于aggregate. domain object之间的关系如果非常复杂，在domain knowledge涉及比较复杂的rule的时候，容易造成不一致的情况。解决办法是，把一些domain object放一个组里，让某个domain object作为根（aggregate root）, 所有对这些domain object的访问都要通过这个aggregate, 那么维持一致性的工作，就限制在这个aggregate root里了。
另一个相关理论是factory和repository. factory是用来“创建”对象的，是一个从无到有的过程。而repository是用来retrieve对象的，也就是说，对象客观存在，只是没有放在内存中，repository就是把数据从某个地方（通常是数据库）拿出来，construct成对象的。一个常见的设计是，让repository暴露retrieve和create的api，但是create的具体工作代理给factory来做，也就是说，factory通常被聚合在repository中。