苏州高端网站设计制作,wordpress改固定连接,肇庆专业网站建设服务,公司网站在哪备案在上一部分#xff0c;分层架构的目的是为了将业务规则剥离出来在单独的领域层中进行实现。再回顾一下领域驱动设计的分层中应用层代码的实现。 Override
public void pay(int orderId, float amount) {DesignerOrder order designerOrderRepository.selectByKey(orderId); …在上一部分分层架构的目的是为了将业务规则剥离出来在单独的领域层中进行实现。再回顾一下领域驱动设计的分层中应用层代码的实现。 Override
public void pay(int orderId, float amount) {DesignerOrder order designerOrderRepository.selectByKey(orderId); // 领域对象的加载if (order null) {AppException.throwAppException(AppExceptionMessage.DESIGNER_ORDER_NOT_EXIST_CODE, AppExceptionMessage.DESIGNER_ORDER_NOT_EXIST, orderId);}order.pay(amount); // 领域对象业务规则实现designerOrderRepository.update(order); // 领域对象状态持久化
} 所有的业务规则都抽象到领域对象比如“order.pay(amount)”抽象了付款的业务规则。领域对象由状态对象的字段、属性和操作对象的方法构成领域对象的操作用于实现业务规则业务规则执行完成后更改领域对象的状态。领域对象的持久化交给了基础设施层这里Repository目的是持久化领域对象状态。 领域驱动设计即领域模型驱动程序设计它的核心是保证系统的实现与实际的业务规则一致完整实现了领域模型。它包含了两个部分领域模型、领域模型的编程实现。 在软件设计和实现过程中要充分利用领域模型设计过程中领域模型作为与业务专家的沟通语言实现过程中领域模型作为与开发人员沟通的语言。领域模型在软件生命周期过程作为通用语言。 1 领域模型 领域建模这里不重点介绍如何建模方法论产出领域模型。我们可以使用UML建模使用最简单、最容易理解的名词-形容词-动词法对领域知识进行建模使用该模型作为与业务、技术团队沟通的通用语言。 在名词-形容词-动词法建模方法中领域知识中的名词一般对应模型、形容词对应模型属性、动词对应模型方法。模型之间的关系有组合、聚合、关联、依赖四者关系由强到弱。 依赖(Dependency)关系是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言依赖关系在Java语言中体现为局域变量、方法的形参或者对静态方法的调用。 关联(Association关系是类与类之间的联接它使一个类知道另一个类的属性和方法。关联可以是双向的也可以是单向的。在Java语言中关联关系一般使用成员变量来实现。 聚合(Aggregation) 关系是关联关系的一种是强的关联关系。聚合是整体和个体之间的关系。例如汽车类与引擎类、轮胎类以及其它的零件类之间的关系便整体和个体的关系。与关联关系一样聚合关系也是通过实例变量实现的。但是关联关系所涉及的两个类是处在同一层次上的而在聚合关系中两个类是处在不平等层次上的一个代表整体另一个代表部分。 组合(Composition) 关系是关联关系的一种是比聚合关系强的关系。它要求普通的聚合关系中代表整体的对象负责代表部分对象的生命周期组合关系是不能共享的。代表整体的对象需要负责保持部分对象和存活在一些情况下将负责代表部分的对象湮灭掉。代表整体的对象可以将代表部分的对象传递给另一个对象由后者负责此对象的生命周期。换言之代表部分的对象在每一个时刻只能与一个对象发生组合关系由后者排他地负责生命周期。部分和整体的生命周期一样。 简而言之组合关系表示部分与整体关系部分不能单独存在聚合关系表示稍弱的部分与整体关系部分可以单独存在关联关系是一个模型和另一个模型的联接比如一个订单有一个顾客而一个顾客有多个订单依赖是最弱的关系表示一个模型的实现使用到另一个模型的功能。 举个例子我们与业务专家沟通梳理了如下业务知识然后我们使用名词-形容词-动词法来进行建模。 领域知识装修设计预约平台1 客户通过系统预约设计师进行装修设计客户只能预约一个设计师订单不能预约多个同时进行设计。2 预约后设计师上门进行量房根据面积进行报价和预估设计时间。设计师订单按照4个节点预估交付时间在不同节点交付不同成果这四个节点分别为平面图、效果图、施工图、交底四个节点的付款比率分别为10%、40%、40%、10%。3 客户接受报价方案后进行付款设计师开始设计如果拒绝则设计师可以进行再次报价和预估设计时间。4 客户在付款之前都可以进行终止。5 客户付款后正式进入设计阶段。设计师按阶段推进设计并按阶段更新进度。在每一个阶段设计师完成任务后客户进行阶段成果确认客户确定后所有阶段后订单自动完成。6 客户可以对完成的订单进行评价。7 客户对已付款但未完成的订单可以提出退款申请退款计算方法依据当前设计进度如果当前进度已经达到设计师请求施工图设计确认进度或超过该进度则不允许退款。如果允许退款退款金额最多为总额 - 已完成的各阶段付款之和最少为未完成交付节点的待付款总额。8 申请通过的退款订单不再允许更新进度。 在这里我们可以梳理出来的名词有客户、设计师订单、设计师、订单交付进度与交付节点、退款订单。和设计师订单有关的动词有量房、报价、接受拒绝报价、取消、付款、确认进度、退款、评价等。设计师订单有关的属性有订单金额、支付金额、面积、取消原因、评价、状态等。 因此我们通过使用名词-形容词-动词法构建的模型图如下所示。 这里模型有客户Customer设计师Designer设计师订单DesignerOrder退款单RefundOrder设计进度DesigningProgressReport设计进度节点DesigningProgressNode。模型中组合关系为设计进度DesigningProgressReport设计进度节点DesigningProgressNode其它模型之间的关系为关联关系。 这个模型就作为软件开发和维护过程的通用语言。接下来我们将介绍如何来实现领域模型。 2 领域模型实现 在上一节我们介绍了通过领域建模来构建了领域模型。接下来我们要介绍如何实现模型驱动程序设计即我们如何通过代码来实现领域模型对应的业务逻辑。领域模型的实现代码在领域层它完整实现了领域模型的内部结构和模型之间的关系。 领域模型的实现代码由以下几个部分构成 • 领域模型关系的实现组合、聚合、关联、依赖。 • 领域模型的实现实体和值对象。 • 跨领域模型的业务规则的实现领域服务。 2.1 领域模型关系的实现 聚合、组合、关联关系在实现上的表现基本上是一个类或者类的标识作为另一个类的属性而依赖关系则是一个类作为另一个类在方法的实现上的参数、变量为另一个类提供功能实现。 下面我们简单看一下如何通过编码来实现类关联关系比如在模型上客户和设计师订单是关联关系一个客户可以有多个设计师订单但是每一个设计师订单只能有一个客户和一个设计师并且最多只有一个退款订单。 1聚合、组合、关联表现在一个类持有另一个类的引用引用可以是实例的引用或者标识的引用具体实现为属性。这种关系是双向关系为了简化编码可能只需要一方持有另一方的引用即可这依赖于具体要实现的业务逻辑。如下代码实现了DesignerOrder对设计师、进度报告的关系。 public class DesignerOrder implements EntityDesignerOrder {private int id;private int designerId;private DesigningProgressReport progressReport;……public Designer getDesigner() {return designerRepository.getDesignerById(this.designerId);}public DesigningProgressReport getProgressReport() {return this.progressReport; }……
} 2依赖依赖表现在一个类的实现使用到另一个类的功能依赖的类可能作为方法的参数、方法局部变量或者静态引用等。如下代码体现了对DesignerOrderWorkflowService的功能依赖。 public class DesignerOrder implements EntityDesignerOrder {public void pay(float amount) {Assert.isTrue(amount 0, The amount must be bigger than 0.);if (!DesignerOrderWorkflowService.canChangeState(state, DesignerOrderState.PAID)) {BusinessException.throwException(DomainExceptionMessage.PAYMENT_NOT_IN_READY_STATE_CODE, DomainExceptionMessage.PAYMENT_NOT_IN_READY_STATE, this.id, this.state);}if (Math.abs(amount - this.expectedAmount) 0.01) {BusinessException.throwException(DomainExceptionMessage.PAYMENT_NOT_MATCHED_CODE, DomainExceptionMessage.PAYMENT_NOT_MATCHED, this.id, this.expectedAmount, amount);}this.state DesignerOrderWorkflowService.changeState(this.id, state, DesignerOrderState.PAID);this.actualPaidAmount amount;// 付款完成后自动启动进度跟踪this.progressReport.startup();}
} 2.2 领域模型的实现 领域模型在实现上表现为两类1实体Entity这个领域模型有特定的标识但是其内部状态会随着一序列的事件对应业务规则的执行发生变化我们把这类模型的实现称为实体2值对象Value Object这个领域模型由属性来定义实例创建后不会发生变更变更也意味着重新创建一个实例我们把这类模型的实现称为值对象。 1实体在装修设计预约平台的领域模型里面我们很容易可以发现设计师订单就是一个实体在创建后每一个设计师订单有一个唯一的订单号后续有量房、报价、付款、退款等系列动作的发生从而订单的内部状态字段值会发生变化但是都代表的是同一个订单。每一个实体的实现都有一个标识。如下所示这里的id字段表示了订单的唯一标识并实现了Entity接口Entity接口sameIdentityAs方法判断实体的Id是否相同。 实体的属性和操作对应着模型的状态和状态的变更他们与模型的定义使一致的。 Data
EqualsAndHashCode(of {id})
public class DesignerOrder implements EntityDesignerOrder {private int id;private DesignerOrderState state;private int customerId;private int designerId;private float area;private float expectedAmount;private int estimatedDays;private DesigningProgressReport progressReport;private String abortCause;private float actualPaidAmount;private int feedbackStar;private String feedbackDescription;private Date createdTime;private Date updatedTime;Overridepublic boolean sameIdentityAs(DesignerOrder other) {return this.equals(other);}public void measure(float area) {Assert.isTrue(area 0, The area must be bigger than 0.);this.state DesignerOrderWorkflowService.changeState(this.id, state, DesignerOrderState.MEASURED);this.area area;}public void quote(float amount, int[] estimatedDaysList) {Assert.isTrue(amount 0, The price must be bigger than 0.);this.assertEstimatedDaysList(estimatedDaysList);this.state DesignerOrderWorkflowService.changeState(this.id, state, DesignerOrderState.QUOTED);this.expectedAmount amount;this.progressReport DesigningProgressReportFactory.newReport(this, estimatedDaysList);this.estimatedDays this.progressReport.getEstimatedCompletionDays();}private void assertEstimatedDaysList(int[] estimatedDaysList) {if (null estimatedDaysList || estimatedDaysList.length ! 4) {throw new IllegalArgumentException(The size of estimatedDaysList must be 4.);}for (int days : estimatedDaysList) {if (days 0) {throw new IllegalArgumentException(Each element of estimatedDaysList must be bigger than 0.);}}}public void pay(float amount) {Assert.isTrue(amount 0, The amount must be bigger than 0.);if (!DesignerOrderWorkflowService.canChangeState(state, DesignerOrderState.PAID)) {BusinessException.throwException(DomainExceptionMessage.PAYMENT_NOT_IN_READY_STATE_CODE, DomainExceptionMessage.PAYMENT_NOT_IN_READY_STATE, this.id, this.state);}if (Math.abs(amount - this.expectedAmount) 0.01) {BusinessException.throwException(DomainExceptionMessage.PAYMENT_NOT_MATCHED_CODE, DomainExceptionMessage.PAYMENT_NOT_MATCHED, this.id, this.expectedAmount, amount);}this.state DesignerOrderWorkflowService.changeState(this.id, state, DesignerOrderState.PAID);this.actualPaidAmount amount;// 付款完成后自动启动进度跟踪this.progressReport.startup();}public RefundOrder refund(String cause) {this.assertCanRefund();this.state DesignerOrderWorkflowService.changeState(this.id, state, DesignerOrderState.REFUND);return RefundOrderFactory.newRefundOrder(this, cause);}
} DDD对于实体有一段重要描述当一个对象由其标识而不是属性区分时那么在模型中应该主要通过标识来确定该对象的定义。使类定义变得简单并集中关注生命周期的连续性和标识。定义一种区分每个对象的方式这种方式应该与其形式和历史无关。要格外注意那些需要通过属性来匹配对象的需求。在定义标识操作时要确保这种操作作为每个对象生成唯一的结果这可以通过附加一个保证唯一性的符号来实现。这种定义标识的方法可能来自外部也可能是由系统创建的任意标识符但它在模型中必须是唯一的标识。模型必须定义出“符合什么条件才算是相同的事务”。 2值对象在货物运输系统中当我们为一个货物的运输执行一条路线之后那么这条路线不能发生变更我们倾向于把路由线路看做一个值对象。如下图所示。对于值对象通过属性值即可标识。 public class RouteSpecification extends AbstractSpecificationItinerary implements ValueObjectRouteSpecification {private Location origin;private Location destination;private Date arrivalDeadline;public RouteSpecification(final Location origin, final Location destination, final Date arrivalDeadline) {Validate.notNull(origin, Origin is required);Validate.notNull(destination, Destination is required);Validate.notNull(arrivalDeadline, Arrival deadline is required);Validate.isTrue(!origin.sameIdentityAs(destination), Origin and destination cant be the same: origin);this.origin origin;this.destination destination;this.arrivalDeadline (Date) arrivalDeadline.clone();}public Location origin() {return origin;}public Location destination() {return destination;}public Date arrivalDeadline() {return new Date(arrivalDeadline.getTime());}Overridepublic boolean isSatisfiedBy(final Itinerary itinerary) {return itinerary ! null origin().sameIdentityAs(itinerary.initialDepartureLocation()) destination().sameIdentityAs(itinerary.finalArrivalLocation()) arrivalDeadline().after(itinerary.finalArrivalDate());}Overridepublic boolean sameValueAs(final RouteSpecification other) {return other ! null new EqualsBuilder().append(this.origin, other.origin).append(this.destination, other.destination).append(this.arrivalDeadline, other.arrivalDeadline).isEquals();}Overridepublic boolean equals(final Object o) {if (this o) return true;if (o null || getClass() ! o.getClass()) return false;final RouteSpecification that (RouteSpecification) o;return sameValueAs(that);}Overridepublic int hashCode() {return new HashCodeBuilder().append(this.origin).append(this.destination).append(this.arrivalDeadline).toHashCode();}
} 值对象Value Object所包含的属性应该行程一个概念整体。当我们只关心一个模型元素的属性时应该把它归类为Value Object。我们应该使这个模型元素能够表示出其属性的意义并为它提供相关功能。Value Object应该是不可变的。不要为它分配粉盒标识而且不要把它设计成像Entity那么复杂。 2.3 跨领域模型的业务规则的实现 我们使用领域服务来封装不属于领域模型或者领域模型公共的业务规则。领域服务的方法一般是静态的并且不会更改内部状态。在装修设计预约平台里面我们使用状态机工作流服务实现订单状态流转它可以在设计师订单和退款单中共用。在《领域驱动设计》里面有一个示例展示了转账服务的实现转账动作实现的是从一个账户到另一个账户的资金流转因此将转账设计到领域服务TransferService里面。关于服务的描述是当领域中的某个重要的过程或转换操作不属于实体或值对象的自然职责时应该在模型中添加一个作为独立接口的操作并将其声明为Service。定义接口时要使用模型语言并确保操作名称是领域模型的术语。此外应该将Service定义为无状态的。 以下是服务示例。 public class DesignerOrderWorkflowService {private DesignerOrderWorkflowService() { }private static MapDesignerOrderState, DesignerOrderState[] states new HashMap();static {states.put(DesignerOrderState.NEW, new DesignerOrderState[]{ DesignerOrderState.MEASURED, DesignerOrderState.ABORTED });states.put(DesignerOrderState.MEASURED, new DesignerOrderState[]{ DesignerOrderState.QUOTED, DesignerOrderState.ABORTED });states.put(DesignerOrderState.QUOTED, new DesignerOrderState[]{ DesignerOrderState.ACCEPT_QUOTE, DesignerOrderState.REJECT_QUOTE, DesignerOrderState.ABORTED });states.put(DesignerOrderState.REJECT_QUOTE, new DesignerOrderState[]{ DesignerOrderState.QUOTED, DesignerOrderState.ABORTED });states.put(DesignerOrderState.ACCEPT_QUOTE, new DesignerOrderState[]{ DesignerOrderState.PAID, DesignerOrderState.ABORTED });states.put(DesignerOrderState.PAID, new DesignerOrderState[]{ DesignerOrderState.REFUND, DesignerOrderState.COMPLETION });states.put(DesignerOrderState.COMPLETION, new DesignerOrderState[]{ DesignerOrderState.FEEDBACK });states.put(DesignerOrderState.ABORTED, new DesignerOrderState[]{ DesignerOrderState.FEEDBACK });states.put(DesignerOrderState.REFUND, new DesignerOrderState[]{ DesignerOrderState.FEEDBACK });states.put(DesignerOrderState.FEEDBACK, new DesignerOrderState[]{ DesignerOrderState.FEEDBACK }); // 允许多次评价}public static boolean canChangeState(DesignerOrderState state, DesignerOrderState nextState) {Assert.notNull(state, The state can not be null.);Assert.notNull(nextState, The nextState can not be null.);DesignerOrderState[] nextStates states.get(state);for (DesignerOrderState possibleNextState : nextStates) {if (possibleNextState.equals(nextState)) {return true;}}return false;}public static boolean canAbort(DesignerOrder order) {return canChangeState(order.getState(), DesignerOrderState.ABORTED);}public static DesignerOrderState changeState(long orderId, DesignerOrderState state, DesignerOrderState nextState) {if (!canChangeState(state, nextState)) {BusinessException.throwException(DomainExceptionMessage.STATE_CHANGE_ILLEGAL_CODE, DomainExceptionMessage.STATE_CHANGE_ILLEGAL, orderId, state, nextState);}return nextState;}public static boolean isCompleted(DesignerOrder order) {return order.getState() DesignerOrderState.ABORTED ||order.getState() DesignerOrderState.REFUND ||order.getState() DesignerOrderState.COMPLETION ||order.getState() DesignerOrderState.FEEDBACK;}
} 3 领域模型生命周期管理 领域模型的创建会包含业务规则我们应该将这些业务规则封装起来使创建过程对应用层透明这里引入Factory来实现创建。此外对于实体发生一系列事件后其内部状态发生了变更这些状态变更需要持久化以使得应用程序能够恢复实体状态。对于值对象我们可能也需要持久化相应的属性。这里我们引入Repository来实现持久化管理。对于一些关联很紧密的对象比如采购订单和商品他们需要共同的满足一个规则比如采购订单里面的商品的总额不能超过采购订单的限额如果多个用户同时变更采购订单或者其包含的商品就需要引入很复杂的锁。为了使关联紧密的对象在整个生命周期都保持一致性我们引入了聚合Aggregate通过它来实现一致性。 总结一句话创建阶段——Factory用于封装实现领域对象创建的业务规则创建、修改——Aggregate用于封装紧密关联领域对象在生命周期内的数据一致性存储——Repository用于封装领域对象持久化的逻辑。 3.1 紧密关联的领域对象的一致性维护—Aggregate 首先我们先看一下为什么要引入Aggregate。这里以采购订单为例子采购员创建采购订单时需要指定限额然后增加采购项目因此可能存在两个采购员对同一个创建的采购订单进行操作来更改订单。 如下所示对于采购订单0012946当前的商品金额为700限额为1000。采购员A可能更改商品项1的数量为5其总额为900满足限额采购员B可能更改商品项2的数量为3其总额也为900满足限额。 当采购员A、B同时提交更新后采购订单的总额为1100超过了1000元限额破坏了业务规则。 在传统的方法当我们采用以下方式更新采购订单商品就会出现刚才破坏业务规则的情况发生。 PurchaseOrder purchaseOrder purchaseOrderBiz.getByKey(“0012946”);ListPurchaseOrderItem purchaseOrderItems purchaseOrderItemBiz.getByOrderId(“0012946”);
changePurchaseOrderItems(purchaseOrderItems);
if (new PurchaseOrderApprovedLimitSpecify(purchaseOrderItems, purchaseOrder).isSatisfied()) {purchaseOrderItemBiz.updateBatch(purchaseOrderItems);
} 为了避免发生采购订单限额的业务规则被破坏对采购订单项的变更需要对采购订单加排它锁。 在DDD里面引入了聚合Aggregate来解决这个问题。Aggregate时一组相关对象的集合作为数据修改的单元在整个生命周期中满足固定的业务规则。每个Aggregate都有一个根root和一个边界boundary。边界定义了Aggregate的内部都有什么根则是Aggregate中所包含的一个特定Entity。在Aggregate中根是唯一允许外部对象保持对它的引用的元素而边界内部的对象则可以互相引用。基于聚合我们来实现一致的采购订单业务规则如下。 1应用层通过以下方式来更新聚合根里面的内容这里必须满足一致性规则对聚合内部实体的状态变更只能通过聚合根来实现通过聚合根来维持业务一致性。 PurchaseOrder order purchaseOrderRepository.load(id);
order.addItem(…)/removeItem(…)/updateItem(…); // 注意这里是重点对聚合根内部的变更只能通过聚合根不能通过获取内部对象进行操作
purchaseOrderRepository.save(order); 2聚合根对内部实体的状态变更如下。 public class PurchaseOrder {private PurchaseOrderItemRepository orderItemRepository;private ListPurchaseOrderItem orderItems;// ……public void addItem(int itemId, int count) {PurchaseOrderItem orderItem PurchaseOrderItemFactory.create(this, itemId, count);orderItems.add(orderItem);if (!new PurchaseOrderApprovedLimitSpecification(this).isSatisfied()) {BusinessException.throwException(…);return;}orderItemRepository.save(orderItem);this.updateTimestamp();}// ……
} 聚合根定义的规则如下 • 根Entity具有全局标识它最终负责检查固定规则。 • 根Entity具有全局标识。边界内的Entity具有本地标识这些标识只有在Aggregate内部才是唯一的。 • Aggregate外部的对象不能引用除根Entity之外的任何内部对象。根Entity可以把对内部Entity的引用传递给它们但这些对象只能临时使用这些引用而不能保持引用。根可以把一个Value Object的副班传递给另一个对象而不必关心它发生什么变化因为它只是一个Value不再与Aggregate有任何关联。 • 作为上一条规则的推论只有Aggregate的根才能直接通过数据库查询获取。所有其他对象必须通过关联的遍历才能找到。 • Aggregate内部的对象可以保持对其他Aggregate根的引用。 • 删除操作必须一次删除Aggregate之内的所有对象。 • 当提交对Aggregate彬姐内部的任何对象的修改时整个Aggregate中的所有固定规则都必须被满足。 3.2 领域模型的创建—Factory 当创建一个对象或创建整个Aggregate时如果创建工作很负责或者暴露了过多的内部结构则可以使用Factory进行封装。领域模型的创建也可能隐含了业务规则Factory可以向应用层屏蔽业务规则。以下是一个设计师订单的Factory类。 public class DesignerOrderFactory {private DesignerOrderFactory() {}public static DesignerOrder createOrder(int customerId, int designerId) {DesignerOrder designerOrder new DesignerOrder();designerOrder.setCustomerId(customerId);designerOrder.setDesignerId(designerId);designerOrder.setState(DesignerOrderState.NEW);return designerOrder;}
} 结论应该将创建复杂对象的实例和聚合的职责转移给一个单独的对象这个对象本身在领域模型中可能没有职责但它仍是领域设计的一部分。提供一个封装所有复杂装配操作的接口而且这个接口应该不需要上层引用要被实例化的对象的具体类。在创建Aggregate时要把它作为一个整体并确保它满足固定规则。 3.3 领域模型的持久化—Repository Repository的目的是实现领域对象的持久化用于领域对象关联查询、重建、添加和删除。我们只为那些确实需要直接访问的Aggregate提供Repository将所有对象的存储和访问操作交给Repository。如下是一个实例。 Repository
public class DesignerOrderRepositoryImpl implements DesignerOrderRepository {private static final String DESIGNER_ORDER_TABLE designer_order;Autowiredprivate DesignerOrderMapper designerOrderMapper;Overridepublic void create(DesignerOrder order) {if (designerOrderMapper.create(order) 0) {TableException.throwTableException(DESIGNER_ORDER_TABLE, TableOperation.CREATE);}}Overridepublic DesignerOrder selectByKey(int id) {DesignerOrder order designerOrderMapper.selectByKey(id);buildConnection(order);return order;}Overridepublic DesignerOrder selectOneBySpecification(DesignerOrder example) {DesignerOrder designerOrder designerOrderMapper.selectOneBySpecification(example);buildConnection(designerOrder);return designerOrder;}Overridepublic ListDesignerOrder selectBySpecification(DesignerOrder example) {ListDesignerOrder designerOrders designerOrderMapper.selectBySpecification(example);buildConnection(designerOrders);return designerOrders;}Overridepublic void update(DesignerOrder order) {if (designerOrderMapper.update(order) 0) {TableException.throwTableException(DESIGNER_ORDER_TABLE, TableOperation.UPDATE);}}
} 4 结论 领域驱动设计的模式如下所示。 综上领域层的实现由聚合构成每一个聚合通常包含了聚合根和领域模型实现、Service、工厂、Repository、领域异常等。 最终装修设计预约平台的领域模型如下所示。 转载于:https://www.cnblogs.com/baihmpgy/p/10760324.html
