领域驱动分析

 主要从三个维度去考虑

1        静态
静态主要是考虑关系学，分为包的关系，类的关系，通过不同层次的关系，分而治之，形成一个良性有序的关系类图。

注意该关系不同于DB中的关系。DB中的关系是用键来指示表之间的关联，关系单调，不能反映出丰富的继承，组合，层次关系语义。如果给键值加上类型的考虑，可以模拟一部分类之间的关系类型。  

类之间的关系更丰富，而且可以动态增删改，可以抽象。  这也是DB与类之间映射失配的关键。 而hibernate其实可以看成是DBMS上面的一个代理层，或是解释层，把丰富的类关关系映射成单调的DB关系。

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

3        领域

针对静态，动态关系的分析和划分时，都是从领域的角度，在领域知识下指导进行的。划分的结果（如不同的层，不同的包）都是综合了动静领域三方面的考量，其中领域是决定性因素。而领域知识中的元素之间的关系组织又需要从静态和动态的角度去分析。

3.1.可以先得出领域中主要的显式概念和关系。然后利用领域的职责来进行模型的横向分层，利用领域的业务目标来进行类的纵向切割。

3.2.横纵之后，在单个层中及某一纵向块中，在领域目标及相关知识的指导下，充分从动静两方面去考虑和分析，这时分析模式和设计模式就可以大展拳脚了。利用我们在软件实现中的经验，复用并修改创造已有的优秀模式，去组织建模领域的类和关系分层图。

3.3.  第1和第2步是迭代过程，也就是模型的精化。因为动静的分析不可避免会影响到职责和目标的重新划分。而职责和目标也会影响到动静态关系的组织方式的选择（关系的组织不会只有唯一的必然选择）。

3.

4. 在此过程中。会逐步分析出许多不属于领域的东西或说多数模型均存在的问题。

3.4.1通用型服务：存储，安全，事务，创建，权限，单点登录。  AOP来介入

3.4.2. 与其他系统的协调：模型映射，概念映射，关系映射，映射维护。只能是在不同的模型层中去协调，可以采用防腐层，结合模式（proxy, decrator, delegate, adapator）解决

3.4.3.  比较难处理的地方：创建职责，可变性处理。 Spring来负责

转载于:https://www.cnblogs.com/boycott2/archive/2008/06/24/1228812.html