1、实体（引用对象）
对象建模倾向于引导我们将精力集中于对象的属性上，但实体的基本概念就是一种抽象的连续性。这种连续性贯穿了对象的整个生命周期，甚至要经历多种实现形式。
有些对象并不主要是由他们的属性来定义的。它们体现了标识在时间上的延续性，经常要精力多种不同的形态。有时，一个对象与另一个对象有着不同的属性，但它们是互相匹配的；有时，一个对象与另一个对象有着不同的属性，但它必须能够跟那么对象区分开来，弄错对象标石会导致数据破坏。
2、值对象
如果我们只关心模型中一个元素的属性，那么久把这个元素划分为值对象。用它来描述它要表述的那些属性的意义，并提供相应的功能。把值对象看成是不可变的。不要给它任何标识，这样可以避免实体的维护工作，降低设计的复杂性。
3、服务
领域中得一些概念不能作为模型中得对象来处理。将领域需要的功能强行加给实体和值对象，不仅会破坏模型中对象的定义，而且还会人为地添加没有意义的对象。
……
当领域中得一个重要进程或转换操作不是实体或值对象的职责时，把操作作为一种独立的接口加入模型，并声明为服务。根据模型中使用的语言来定义接口，保证操作名是通用语言的一部分。使这个服务变成无状态的。
4、模块（包）
模块是一种老的、确定的设计元素。这里有技术方面的考虑，但主要还是出于模块化的考虑。模块给热门提供了两种分析模型的方法，以模块为单位考虑它实现的细节，或者从全局分析模块之间的联系，而不用关心细节。
领域曾的模块应该是模型中有意义的一部分，从较大的方面来描述领域。
每个人都使用模块，但是很少有人将它们看作是模型中一个完整的部分。在开发人员使用的技术框架中，代码被分门别类地进行划分。甚至就那些经常重构模块的开发人员，也常常使用以前项目中设计好的模块。
的确应该实现模块间的低关联和模块内的高内聚。对于关注和内聚的解释，听上去往往像是技术上的衡量标准，用来机械地判断模块相互联系和相互作用的分布情况。除代码外还将概念都分成了模块。一个人在某个时刻所能考虑到的事情是有限的（低关联）。不连贯的思维是很难被理解的，也很难表现出统一的想法（高内聚）。
……
选择的模块应该能够描述提供，包含的概念集应该是内聚的。这样会在模块间产生松散关联，如果不是，就想办法改变模型，重新整理概念。或是寻找一种概念，构成模块的基础，以一种有意义的方式把元素集中起来。寻找概念中的低关联，能够理解并解释它们之间的相互独立性。对模型进行精炼，直到模型能够根据高级的领域概念进行划分，同事分离相应的代码。
给模块命名，并把这些模块名加到通用语言中。模块和它们的名称应该反映出对领域的理解。
5、在混合范式中使用模型驱动设计
根据把非对象元素添加到一个面向对象系统中得经验，可以得出下面4个规则。
不要否定实现范式。总是可以用其他的方法来考虑领域。找出适合这个范式的模型概念。
依靠通用语言。尽管工具间没有严格的联系，坚持使用术语可以保持设计的各部分不会出现差异。
不要担心UML的能力。有时候，由于工具上的限制，例如UML图，会误导人们破坏模型来迁就这些图标。例如，UML确实有些用来表示约束的特性，大师它们总是不很充分。另外一些绘图风格（可能是其他范式的图标管理），或简单的文字描述，都比强行去适应一种绘图风格好得多。
要保持怀疑的态度。工具是否它真正的作用？因为您已经有了一些规则，这久意味着没有必要使用规则引擎。虽然规则能够被描述成对象，但多个范式会使问题变得非常复杂。