DDD

http://www.jdon.com/jivejdon/thread/34255.html
1． 主要从三个维度去考虑
1.1 静态
静态主要是考虑关系学，分为包的关系，类的关系，根的聚合关系，通过不同层次的关系，分而治之，形成一个良性有序的关系类图。
类的关系：领域职责和业务决定
根的聚合：主要考虑不变量关系，那些类应该在此根聚合中，并保持不变量关系，那些在此聚合中，但不在不变量范围之内。目的是为了既保持此聚合的内存和存储的一致性（修改其中元素，锁定根，这样就可以保持一致）， 同时又要保持远离高并发（挑出活跃修改的元素，以防止保护范围不合适，锁定太频繁，性能太差）。
注意该关系不同于DB中的关系。DB中的关系是用键来指示表之间的关联，关系单调，不能反映出丰富的继承，组合，层次关系语义。如果给键值加上类型的考虑，可以模拟一部分类之间的关系类型。
类之间的关系更丰富，而且可以动态增删改，可以抽象。 这也是DB与类之间映射失配的关键。 而Hibernate其实可以看成是DBMS上面的一个代理层，或是解释层，把丰富的类关关系映射成单调的DB关系。


1.2 动态
1. 应用层次：动态主要是针对业务中的一些业务流程来进行建模。这主要要考虑因动作而导致的一系列相关因素的变化的原子性，一致性。包括单个行为（或方法）的原子一致性，多个行为的原子性，一致性。相对应用层就是每操作(per operation)，每请求(per request)，每会话(per conversation)的原子性，一致性。 这主要映射到应用层的（离线）悲观乐观锁，或DB层的悲观乐观锁或是隔离级。
2. 操作层次：主要针对具体业务操作单元中的可变性。动态还要针对类之间的职责协作， 也就是具有静态关系的类之间的协作。这里面除了类之间的相互调用 ，更主要的需要充分考虑到策略，规则，计算的可变性（可能采用新策略），具体来说如：排序策略，搜索策略，存储策略，计费规则，计税规则，验证规则，过滤规则，贴子中的评分规则，精华评估策略，类似贴子，相关贴子的选择计算策略等。不同行业中，主要的业务往往保持稳定，但在业务中的一些相关规则策略是灵活多变的。这主要映射到一些设计模式：proxy,decorator,adaptor,command，chain等。

1.3 领域
针对静态，动态关系的分析和划分时，都是从领域的角度，在领域知识下指导进行的。划分的结果（如不同的层，不同的包）都是综合了动静领域三方面的考量，其中领域是决定性因素。而领域知识中的元素之间的关系组织又需要从静态和动态的角度去分析。
1.可以先得出领域中主要的显式概念和关系。然后利用领域的职责来进行模型的横向分层，利用领域的业务目标来进行类的纵向切割。
2.横纵之后，在单个层中及某一纵向块中，在领域目标及相关知识的指导下，充分从动静两方面去考虑和分析，这时分析模式和设计模式就可以大展拳脚了。利用我们在软件实现中的经验，复用并修改创造已有的优秀模式，去组织建模领域的类和关系分层图。
3. 第1和第2步是迭代过程，也就是模型的精化。因为动静的分析不可避免会影响到职责和目标的重新划分。而职责和目标也会影响到动静态关系的组织方式的选择（关系的组织不会只有唯一的必然选择）。例如操作层次的动态性中，可能造成DB的竞争，为了减少竞争， 要注意以聚合的根为存储单元，同时把活跃变化的元素剔出聚合的不变量范围之外。

1.4. 在此过程中。会逐步分析出许多不属于领域的东西或说多数模型均存在的问题。
1通用型服务：存储，安全，事务，创建，权限，单点登录。 AOP来介入
2. 与其他系统的协调：模型映射，概念映射，关系映射，映射维护。只能是在不同的模型层中去协调，可以采用防腐层，结合模式（proxy, decrator, delegate, adapator）解决
3. 比较难处理的地方：创建职责，可变性处理。 Spring来负责


仔细看了下，才发现 “应用层次：动态主要是针对业务中的一些业务流程来进行建模。”，业务流程怎么能放在应用层呢？这肯定是错误的。

我主要是从以下两方面考虑：

这里面的应用层与 系统分层（应用，领域层）中的应用概念不是一个概念。 这里的应用层其实是有点类似于martin flower中的知识层，是说明更高抽象，更高目标，更粗业务粒度的概念。

另外， 对于应用层是否一定不能放业务流程，其实是个仁者见仁的问题，有时我们很难做到分得如此干净。 而对于一些比较固定的流程，其实也可以放入应用层，关键是这个流程要满足以下条件：
1。 固定或说稳定
2， 不涉及业务规则或策略判断
3. 简单：一到二步，顺序组合。
这样应用层的接口，其实也就是组成了一个基本的相对固定的高层业务框架




DB与类之间映射失配，不理解，请举个具体的例子？
映射失配，或者叫阴抗失配。 是指DB关系模型与OO类模型（我把它也看成另一种关系模型，只不过这个模型中的关系是比较灵活，通过多态和模式应用，还具有动态性。 ）之间的映射存在障碍
OO中的关系： 聚合， 组合 ， 继承， 加上设计模式后（其实也就是应用以上三个基本关系的灵技巧性组合）来得到更多的应对不同变化类型的关系。

DB中的关系： 外键关联，主键关联

OO的关系与DB中的关系的转化： 为了让DB的相对简单的关系来映射OO中的丰富关系，我们可以采用外键关联，主键关联， 一表多类， 一类多表，中间表等技巧来持久化类。

这样的映射如果是我们自己来做，写在代码中，就很别扭，也不能聚焦在模型中，容易精力分散到映射OO与DB中， 尤其是更严重的， 这种思路很容易把我们引入以DB关系思考的分析设计，也就DB驱动的分析设计开发。（观点参见DDD一书）。