1.2　当事人领域模型

领域驱动设计已经广泛地被人们接受，当设计一个应用时，人们往往先从领域角度抽象模型，再基于模型之上设计数据库、服务、界面和流程。例如，设计当事人管理系统时所涉及的领域模型包括个人客户和企业客户，按照当事人的定义，它们都属于当事人领域模型。在所有行业中，当事人包含的基本信息几乎相同，如：当事人代码、姓名、性别、出生日期、证件类型、证件号等，但是其他信息或多或少地都有个性化差异。即使在同一个行业，例如不同保险公司，当事人信息也有少许差异，并不完全一致。假设当事人领域模型除了基本信息，还包含多个账户信息，那么当事人模型领域模型可通过Java类PartyBO表示如下：

该类嵌套了一个PartyAccountBO类的列表，表示一个当事人下可以有零到多个账户。PartyAccountBO的定义如下：

设计好PartyBO之后，接着为其设计相关联的服务。当事人没有复杂处理的业务逻辑，一般都是增删改查的简单操作，服务接口定义如下：

在上述服务PartyService接口中，saveParty用于增加或者修改PartyBO对象，getParty根据id获取PartyBO对象，deleteParty删除一个PartyBO对象，getPartyByCode通过当事人代码从数据库中获取PartyBO对象。这些服务接口定义粒度比较粗，几乎适用于所有行业。面向每一个具体行业，当事人服务接口应该不会有太大变化，但是PartyBO类在不同企业中，受限于具体领域模型的需求，将会有很大差异。

只要模型发生了变化，即使保持接口定义原型不变，服务接口具体实现也将发生变化，不同企业的领域模型差异将导致服务无法重用。以具体需求设计领域模型的方式来设计当事人管理系统时，软件的产品化程度很低，无法适用于多家企业。其根本原因在于采用固化模型，缺少抽象，缺乏灵活扩展机制，无法重用。

在同一个企业内部，当事人除个人客户外，还有企业客户，对于企业客户的管理，其服务接口和个人客户管理几乎相同，但是模型变化非常大，个人客户包括姓名、性别、出生日期等信息，而企业客户包含企业登记号、企业名称、注册时间、注册资本等信息。即使企业客户管理都是增删改查这种很类似个人客户管理的功能，但是由于领域模型不同，不得不做两套独立的应用或者服务来分别管理。业务需求稍微变化，都会涉及模型变化，然后引起程序代码修改、数据库表结构修改，反反复复，工作量巨大，都是琐碎重复、没什么技术含量但又是不得不做的工作。