久隆信息领域建模.doc

 FILENAME \* MERGEFORMAT 3171327-58f1b19b5facc.doc 模板版次：3.0第  PAGE 6 页 共  NUMPAGES 6 页COPYRIGHT? 2000- DATE \@ yyyy \* MERGEFORMAT 2017 JITE SHANGHAIISO9001:2000/CMMI5认证企业 领域建模 作者：久隆信息 张晓刚 我们常说“使用领域模型来描述了一个领域的所有对象和他们的关系。领域模型可以捕捉一个系统内，组织内或者任何特定领域的重要对象。” 但是领域模型绝不是一堆带有getter和setter的POJO对象。在说明这个问题之前，我们需要先回答一个问题，什么是领域模型？ 对于“模型”这个词语来说，很容易理解。模型是一种简化，它对现实进行阐述，只是抽象出来与解决手头问题有关的方面而忽略掉无关的细节问题。 每个软件程序都会跟其用户的活动或者兴趣有关，用户在其中使用程序的主要环境被我们称为软件的领域。领域可能会涉及到具体的世界，航班预订程序的领域涉及到登机人，ATM取款涉及到银行账户。 我们开发软件的目标是建立对用户活动有价值的软件，开发团队必须瞄准与这些活动有关的知识主体。对开发人员所要求的知识可能是令人望而生畏的，模型正式这样一种东西，帮助开发人员处理这些信息与知识。一个合适的模型能够让人了解信息的含义并且聚焦于问题本身。 Martin Fowler在 HYPERLINK /books.html \l eaa P of EAA中阐述过，”domain model is an object model of the domain that incorporates both behavior and data”。 注意“behavior and data”。事实上，不止一个人这样认为，Eric Evans在DDD中写到： Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software. （领域层负责表示业务概念，业务状况的信息以及业务规则，尽管保存这些内容的技术细节由基础架构层完，反映业务状况的状态在该层中被控制和使用，这一层是业务软件的核心。） 好了，我想我们已经说的够清楚了。 领域模型是一个高层次的概念模型。一般来说 概念类使用“Class”元素来描述； 每一个概念类包括“属性”和“操作”； 概念模型可以与其他概念模型或者自己本身有关联； 我们现在一谈领域模型，很多人脑子里就想到数据库增删改查。实际上这也就是很多人批评的。贫血的领域模型只关注领域模型的持久化特征方面，而忽略了领域模型其他特征方面的模型，这样的模型是贫血的。因为这种模型只关注了模型在技术层面的外在表现，也就是说只关注了数据的存取操作而忽略了模型蕴含的业务核心价值。 举例来说，我们编一个银行软件，如果你只关注了账户的增删改查，这叫做贫血！而实际上你应该关注的是账户的业务特征，而不是数据特征，你应该关注的是账号开立的业务，账户注销的业务，账号过户的业务等等，这才是领域模型。这种领域模型在一个单纯的技术实现层面来说，对于最简单的业务，你可能只是 Account类的增删改查，但是对于复杂的业务来说，他就不单但是一个类，一个表的简单操作了，例如开立账户，你要收手续费，以及考察个人财务状况，那 么此时你需要的就是一组协作的类。 再举一个例子。员工入职，员工入职以后需要在HR系统中建立基本档案，完成雇佣操作后，需要信息管理部门分配分机、客户端IP，这些信息又返回到HR系统中。 JAVA EYE上有段时间对领域模型进行了热烈的讨论，具体讨论不做描述，详细的可以去看相关的论坛。 Robbin对三种模型贫血、充血、涨血做了总结，这里参考一下 第一种模型：只有getter/setter方法的纯数据类，所有的业务逻辑完全由business object来完成(又称TransactionScript)，这种模型下