Author :
Anders小明 续《
Domain Model:业务对象的进一步设计》
Product Line Product Line体系存在比较特殊,Product Line的概念并不明显。Product Line以Product为核心,维护了一类product所共有的属性与其它关联业务对象如Document,同时维护了不宜在product一级维护的信息:product与其它业务对象与业务逻辑,如与contract的约束关系。具体如下:
Product Line维护Product共有的属性以及关联关系
1. 维护product共有的属性。
这个比较好理解,最类似的是category对象。
2. 维护product共有的关联关系。
这个好理解,目的只在一个点维护,避免无谓重复。
Product Line还维护不宜在product层次维护的信息和逻辑(注:并不是很绝对的,通常而言,以下几种信息和逻辑的维护,在实际应用中都针对product line一级,但在某些业务中,还需要维护特定的product):
1. 维护product与其Visitor对象的关联关系。
Product或者Contract总是需要对User是可视的,《分析模式》的10.5.4专门讨论了这块内容。由于同类的Product的Visitor是有共性的,同时Visitor和Product关系并不是那么直接,甚至对于某些项目来说,同一product line下的所有product的可视性都是一致的,因而在product一级上维护Visitor。
除了单个product的可视性,通常还有product line的search功能。支持Search功能的类型也是在这一级维护的。
2. 维护product与其关联对象的约束关系。
这个是适用于product的定义的用例。当product关系复杂时需要通过给出一些约束关系以保证产品的定义的完整性。比如product都有与其关系document对象,但是document对象又分为多种类型,但对于某类的product需要关联特定三种类型文档,这种约束关系就定义在product line对象上。
3. 维护product与contract的约束关系。
在复杂的业务中,contract和product的关系并不是单向的,除了contract将保持对product的引用外,product也会有限定的contract的适用。比如product的结算的货币;现实的例子是:携程旅行网的电子机票只允许电子银行支付方式;eBay上的某些促销物品只允许快递的送货协议。当然,对于这样的约束关系定义product一级还是product line一级是需要根据项目特点分析的。
4. 维护product与业务流程以及行为的约束关系。
这是比较少见的,但还是存在。例如对于某种类型的product,不允许在业务上做批改动作;对于某类型的产品在业务流程上需要预先填一份业务单据等。相比而言,通常业务流程(主要是页面流)以及业务行为和product line关联,很少见到和某个具体product关联。
Product Line是所知的最麻烦的领域对象体系,包含了很多逻辑在内,显的有点混乱,不过细想还是有点道理的。
分享到:
相关推荐
3. **实体(Entity)与值对象(Value Object)**:在DDD中,实体是有唯一标识的业务对象,而值对象关注的是属性的集合,不考虑其身份。库中可能会定义这些类,以封装业务规则并确保数据的一致性。 4. **聚合...
3. **领域模型(Domain Model)** 领域模型是面向对象设计的核心,它反映了问题领域的概念和它们之间的关系。在这个阶段,我们需要定义类、接口和它们的属性及操作。IBM的实例可能展示了如何根据需求分析结果创建...
对象模型(Object Model)在DDD中占据重要地位,通过实体(Entities)、值对象(Value Objects)和领域服务(Domain Services)构建。实体是拥有唯一标识且生命周期贯穿的应用对象,而值对象则是描述实体属性的不可...
首先,"model"层通常指的是领域模型(Domain Model),它是业务逻辑的核心,包含了对应用中实体和业务规则的抽象。在Java应用中,model类通常用来封装数据,定义业务操作方法,以及实现业务逻辑。建模工具类在此层的...
1. 实体(Entity):具有唯一标识的业务对象,如用户、订单等。实体之间的关系构成了业务逻辑的一部分。 2. 值对象(Value Object):关注于某个属性集合的值,例如地址、颜色等。它们不具有独立的标识,常用于描述...
2. **领域模型(Domain Model)**:领域模型是反映业务领域的核心概念、实体和关系的模型。它包含业务规则和业务逻辑,是OOAD的关键部分。领域模型的构建基于对问题域的理解,通过识别关键实体、属性、操作和它们...
- **概述**:Domain Model 强调通过领域实体来表达业务逻辑,支持更复杂的业务场景。 - **分析**:虽然增加了初始开发成本,但长期来看提高了系统的可维护性和扩展性。 #### 3.5、各种架构模式的比较及选择 - **...
1. 实体(Entity):具有唯一标识的业务对象,其状态和行为由领域模型定义。 2. 值对象(Value Object):关注于值而非身份的对象,例如地址、颜色等。 3. 聚合(Aggregate):由实体和值对象组成,维护业务规则的...
领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法论,旨在帮助开发团队创建高质量的软件解决方案,特别是针对那些业务逻辑极其复杂的系统。它强调将业务领域知识与软件设计紧密结合,以便更好地...
"jcommons-domain-model-jackson"是一个专门为Java设计的库,它结合了jcommons(一个Java通用工具库)和Jackson库的能力,以提供强大的对象到JSON的映射功能。Jackson是Java社区中最受欢迎的JSON处理库之一,因其...
与传统的J2EE架构或Spring+Hibernate的事务性编程模型相比,领域驱动设计更倾向于把业务对象和业务逻辑作为核心,而不是单纯关注数据持久化。在这种模式下,基础设施层为其他层提供支撑,包括数据持久化、通信以及...
在IT行业中,领域模型(Domain Model)是一种重要的软件设计概念,尤其在企业级应用开发中占据核心地位。领域模型是对业务领域的抽象和简化,它包含了业务规则、业务实体以及它们之间的关系。本项目示例旨在提供一个...
- **Domain(实体)层**:封装业务对象。 - **Service层**:封装具体的业务逻辑。 - **Utils层**:包含通用工具类。 - **View层**:负责用户界面的显示。 ##### 2.2 框架的设计 - **前端框架**:可以考虑使用...
充血模型,也被称为“Rich Domain Model”,是领域驱动设计(DDD)中的一种核心概念。在软件开发中,领域模型是对业务领域的抽象和建模,它包含业务规则、逻辑和状态。充血模型强调对象应该拥有自己的行为和状态,而...
- **MVC 框架**:实现模型(Model)、视图(View)与控制器(Controller)分离的设计模式。 - **O/R Mapper**:用于将对象映射到数据库表,实现对象与关系型数据之间的转换。 - **安全性**:确保应用程序的安全性,...
标题 "1975年:1975年-ModelandoDomíniosRicos" 提到的核心概念是“丰富的领域模型”(Rich Domain Model),这是一个软件架构设计中的关键概念,尤其是在面向对象编程和领域驱动设计(Domain-Driven Design, DDD)...
7. 领域层(Domain Layer):包含业务对象和领域规则,是业务逻辑的核心。 在Winform应用中,学习如何有效地组织这七层结构对于提高代码质量、降低维护成本至关重要。你需要理解每个层次的作用,以及它们如何相互...