关联（Association)是一种非常弱的关系，包含聚合、组合两种关系。对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。具体到代码层面，如果B类是A类的成员变量，那么B类和A类就是关联关系。
图例：
使用实线箭头表示。
代码实现：
public class A { private B b; public A(B b){ this.b = b; } }或者
public class A { private B b; public A () { this.b = new B(); } } 依赖(Dependency)介绍：
依赖(Dependency) 是比关联关系更加弱的关系，包含关联关系。不管是B类对象是A类对象的成员变量，还是A类方法使用B类对象作为参数或者返回值、局部变量，只要B类对象和A类对象有任何使用关系，我们都称他们有依赖关系。
图例：
使用 虚线箭头 表示。
代码实现：
public class A { private B b; public A(B b){ this.b = b; } }或者
public class A { private B b; public A () { this.b = new B(); } }或者
public class A { public void func(B b) ... } } 模型简化严格的UML类图之间的关系拆分的太细，专业要求很高，大大增加了学习成本，而且对于业务沟通，指导后续数据库设计，编程开发没有太大意义。
所以在实际业务建模过程中，我们并不需要严格按照UML类图交互关系来描述业务实体之间的关系，比如我们可以将聚合、组合、关联统统使用关联关系表示，使用实线连接两个实体，并在两侧标记出实例个数即可。
领域模型最终呈现后的结果很简单，但是过程却很复杂。需要架构师基于自身的业务知识和类似产品的参考，再结合客户、业务专家、领域专家的咨询和指导，需要经过不断推倒、修改优化才能完成。
对于刚开始接触领域模型的绘制时经常会出现下面两种典型错误：
将待开发系统也放在领域模型里面
待开发系统要不要出现在领域模型中取决于你的业务离开待开发的系统能不能玩的转。举个例子：如果开发的是共享单车的信息系统，共享单车离开信息系统肯定玩不转，所以这时候信息系统需要出现在领域模型。
概念划分不清，关系没有画到位
比如属性画成了类，继承关系搞错