Java EE假设称为域模型.域模型由表示实体的对象组成,其中实体是具有与业务相关的身份的事物.(例如,如果您在银行工作,您的域可能涉及账户,客户,控股和贷款等事项).
以下是Bauer和King的Java Persistence with Hibernate引用域名模型的引用:
3.1.1.分析业务领域
软件开发工作从问题域的分析开始(假设已经存在遗留代码或遗留数据库).
在此阶段,您可以在问题领域专家的帮助下识别与软件系统相关的主要实体.实体通常是系统用户理解的概念:支付,客户,订单,项目,投标等.一些实体可能是用户想到的不太具体的事物的抽象,例如定价算法,但即使这些实际上对用户来说也是可以理解的.所有这些实体都可以在业务的概念视图中找到,我们有时将其称为业务模型.面向对象软件的开发人员和架构师分析业务模型并创建面向对象的模型,仍然处于概念层面(没有Java代码).这个模型可能就像只存在于开发者心中的心理图像一样简单,或者它可以像由ArgoUML或TogetherJ等计算机辅助软件工程(CASE)工具创建的UML类图一样精细.用UML表示的简单模型如图3.1所示.
此模型包含您在任何典型拍卖系统中必须找到的实体:类别,项目和用户.实体及其关系(可能还有它们的属性)都由问题域的这个模型表示.我们将这种面向对象的实体模型称为问题域,仅包含用户感兴趣的实体,即域模型.这是对现实世界的抽象观点.
分析和设计领域模型背后的激励目标是为应用程序的目的捕获业务信息的本质.
理想的情况下(在方法称为领域驱动设计)这些领域对象有2个特点:他们不知道有关的基础设施的担忧像持久性或事务,以及它们所包含的逻辑实现,当他们的业务处理过程中被操纵发生的状态转换; 这些组合意味着业务逻辑可以与基础架构分开测试.在现实世界中,更典型的是看到不包含任何业务逻辑的贫血域对象,业务逻辑都以事务脚本结束.
无论如何,这个想法是你有一个由持久性实体组成的域模型.有某种配置(注释或XML文件或其他)将实体及其属性映射到数据库中的表和列,并映射实体之间的关系.有一个对象关系映射(JPA是实现的ORM标准,Hibernate是一个这样的实现),它知道如何将数据转换来回数据库表示与对象的图形化表示之间,从而使开发人员可以操纵对象,而不是数据库行.
对于声称业务逻辑不应该是域模型的一部分的人,这里是另一篇来自Java Persistence with Hibernate的书,在3.1.2节中:
域模型中的实体应该封装状态和行为.例如,用户实体应定义客户的名称和地址以及计算物料(对该特定客户)的运输成本所需的逻辑.域模型是一个富对象模型,具有复杂的关联,交互和继承关系.有关使用领域模型的面向对象技术的有趣而详细的讨论可以在企业应用程序架构模式(Fowler,2003)或领域驱动设计(Evans,2003)中找到.
在本书中,我们对业务规则或域模型的行为没有多少说法.这不是因为我们认为它不重要; 相反,这种担忧主要与持久性问题正交.这是我们实体的持久性状态,因此我们将讨论集中在如何在域模型中最好地表示状态,而不是如何表示行为.例如,在本书中,我们对如何计算已售商品的税或系统如何批准新用户帐户不感兴趣.我们更感兴趣的是如何表示用户与他们销售的商品之间的关系并使其持久.每当我们仔细研究分层应用程序设计以及逻辑和数据访问的分离时,我们将在后面的章节中重新讨论这个问题.
显然,Hibernate开发人员认为它是一种可行的替代方案,尽管它似乎不是典型企业开发中的常用方法.
| 归档时间： |
|
| 查看次数： |
4666 次 |
| 最近记录： |