本文转载自微信公众号《JAVA日之录》，作者单音。转载本文请联系JAVA日知录公众号。领域模型的概念和作用领域模型是领域中的概念类或现实世界中的对象的可视化表示。也称为概念模型、领域对象模型、分析对象模型。它侧重于分析问题领域本身，发现重要的业务领域概念，并建立业务领域概念之间的关系。这个概念比较深奥。其实说白了，就是我们根据对业务的理解画一个类图，画出这些类之间的关系（面向对象）。领域模型可以梳理业务中的概念和关系，帮助团队成员对业务保持一致的理解，可以指导以后的数据库设计、系统功能设计和开发。在整个系统建设周期中，可以起到上层接收需求，下层承接开发的作用。既然领域模型如此重要，那么我们是不是要在类图中尽可能多地展示对象的属性和方法，以更好地指导后续的开发设计。相反，我们在建模时不应该关注属性或行为，我们应该摆脱这些细节，抓住领域对象定义的最基本特征，只需要反映对象模型的重要概念。细节过多，容易产生“只见树木，不见森林”的现象。我们来看一个简化的报销业务领域模型来加深印象。要完成领域模型的建模，需要做两件事：定义类的关键属性和关键行为；定义类之间的关联关系。定义一个类的属性和行为定义一个类的属性和行为是比较简单的。只需使用设计工具拖动一个类即可。这里只需要关注属性和行为的访问权限即可。-表示private#表示protected~表示default，即包权限+表示public定义类与类之间的交互关系在UML类图中，定义了六个类之间的关系，它们是：Generalization,Realization,Association，聚合，组合，依赖。关系有很多种，也有类似的，比如聚合、组合。接下来我们逐步讲解：泛化简介：泛化表示类之间的继承关系，以及接口之间的继承关系。图例：用空心三角形+实线表示。代码实现：publicclassA{}publicclassBextendsA{}实现介绍：实现是指一个类实现interface接口的功能（可以是多个）。图例：用空心三角形+虚线表示。代码实现：publicinterfaceA{}publicclassBimplementsA{}聚合（Aggregation）介绍：聚合（Aggregation）表示一种弱'拥有'关系，即has-a关系，反映了A对象可以包含B对象，以及A对象的生命周期B类可以不依赖A类对象的生命周期，也就是说可以单独销毁A类对象而不影响B类对象，比如课程和学生的关系。图例：用空心菱形+实心箭头表示。代码实现：publicclassA{privateBb;publicA(Bb){this.b=b;}}Composition介绍：Composition表示一种强'owning'关系，即contains-a的关系，反映了ObjectA包含objectB.B类型的生命周期依赖于对象A的生命周期B类型的对象不能单独存在，比如鸟和它翅膀的关系。图例：用实心菱形+实心箭头表示，也可以用直线两端的数字表示一端有多少个实例。代码实现：publicclassA{privateBb;publicA(){this.b=newB();}}关联（Association）介绍：关联（Association）是一种很弱的关系，包括聚合和组合。对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖于另一个对象的服务时，主要体现两个对象之间的关系。具体到代码层面，如果B类是A类的成员变量，那么B类和A类是相关的。图例：用实线箭头表示。代码实现：publicclassA{privateBb;publicA(Bb){this.b=b;}}或publicclassA{privateBb;publicA(){this.b=newB();}}依赖介绍：依赖是一种弱于关联关系，包括关联关系。不管B类对象是A类对象的成员变量，还是A类方法使用B类对象作为参数或返回值，还是局部变量，只要B类object和A类对象有任何使用关系，我们称之为依赖关系。.图例：用虚线箭头表示。代码实现：publicclassA{privateBb;publicA(Bb){this.b=b;}}或publicclassA{privateBb;publicA(){this.b=newB();}}或publicclassA{publicvoidfunc(Bb)...}}模型简化严格的UML类图拆分的太细，专业要求高，学习成本大大增加。而且对于业务沟通、指导后续的数据库设计、编程开发等意义不大。因此，在实际的业务建模过程中，我们不需要严格按照UML类图的交互关系来描述业务实体之间的关系。实体，并在两侧标记实例数。总结领域模型最终的结果很简单，但是过程却很复杂。架构师需要根据自己的业务知识和同类产品的参考，结合客户、业务专家、领域专家的咨询和指导，不断推翻、修改和优化来完成。刚开始绘制领域模型时，经常会出现以下两个典型的错误：将要开发的系统放在领域模型中。待开发的系统是否出现在领域模型中，取决于你的业务能不能离开待开发的系统。到处玩。举个例子：如果你在开发共享单车的信息系统，没有信息系统共享单车肯定不行，所以这个时候需要在领域模型中出现信息系统。概念划分不清晰，关系绘制不到位。比如把属性画成一个类，继承关系就错了。
