首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

DDD和依赖注入上下文中的实体的状态机?

基础概念

领域驱动设计(Domain-Driven Design, DDD) 是一种软件开发方法论,旨在通过将复杂业务逻辑划分为一系列领域模型来提高软件的可维护性和可扩展性。DDD的核心概念包括实体(Entity)、值对象(Value Object)、聚合(Aggregate)、领域服务(Domain Service)和领域事件(Domain Event)等。

依赖注入(Dependency Injection, DI) 是一种设计模式,用于实现控制反转(Inversion of Control, IoC),通过外部实体提供依赖对象,而不是在类内部创建这些对象。这有助于提高代码的可测试性和可维护性。

状态机(State Machine) 是一种模型,用于描述系统在不同状态下的行为以及状态之间的转换。状态机可以用于管理实体的生命周期和行为。

相关优势

  1. DDD的优势
    • 提高代码的可理解性和可维护性。
    • 通过明确的领域模型,更好地理解和处理复杂的业务逻辑。
    • 促进团队之间的沟通和协作。
  • 依赖注入的优势
    • 提高代码的可测试性,因为依赖对象可以轻松地被模拟或替换。
    • 降低代码的耦合度,使得系统更易于扩展和维护。
    • 提高代码的可读性和可维护性。
  • 状态机的优势
    • 清晰地定义和管理实体的状态和行为。
    • 简化复杂的状态转换逻辑。
    • 提高系统的可预测性和稳定性。

类型

  1. DDD类型
    • 实体(Entity):具有唯一标识符的对象,其状态可以随时间变化。
    • 值对象(Value Object):不可变对象,通常用于描述实体的属性。
    • 聚合(Aggregate):由多个实体和值对象组成的根实体,具有业务意义。
    • 领域服务(Domain Service):处理不属于任何实体的业务逻辑。
    • 领域事件(Domain Event):表示领域中发生的事件。
  • 依赖注入类型
    • 构造函数注入(Constructor Injection):通过构造函数传递依赖对象。
    • 属性注入(Property Injection):通过属性设置依赖对象。
    • 方法注入(Method Injection):通过方法参数传递依赖对象。
  • 状态机类型
    • 状态机可以是简单的有限状态机(Finite State Machine, FSM),也可以是更复杂的层次状态机(Hierarchical State Machine)或状态图(State Diagram)。

应用场景

  1. DDD应用场景
    • 复杂的业务逻辑和领域模型。
    • 需要高度可维护和可扩展的系统。
  • 依赖注入应用场景
    • 需要提高代码的可测试性和可维护性。
    • 需要降低代码耦合度的系统。
  • 状态机应用场景
    • 需要管理实体生命周期和行为的应用。
    • 需要处理复杂状态转换逻辑的系统。

问题及解决方法

问题:在DDD和依赖注入的上下文中,如何管理实体的状态机?

原因:在复杂的业务场景中,实体的状态转换逻辑可能非常复杂,难以管理和维护。

解决方法

  1. 定义清晰的状态和转换
    • 使用状态机模型明确实体的所有状态及其转换条件。
    • 例如,定义一个订单的状态机,包括“新建”、“已支付”、“已发货”、“已完成”等状态及其转换条件。
  • 使用依赖注入管理状态机
    • 将状态机的实现作为一个领域服务,并通过依赖注入提供给需要使用状态机的实体。
    • 例如,定义一个OrderStateMachineService,并通过构造函数注入到Order实体中。
代码语言:txt
复制
public class Order {
    private OrderStateMachineService stateMachineService;

    public Order(OrderStateMachineService stateMachineService) {
        this.stateMachineService = stateMachineService;
    }

    public void pay() {
        stateMachineService.transitionToPaid(this);
    }
}

public class OrderStateMachineService {
    public void transitionToPaid(Order order) {
        // 状态转换逻辑
    }
}
  1. 使用事件驱动的状态转换
    • 通过领域事件触发状态转换,而不是直接在实体方法中调用状态机。
    • 例如,当订单支付成功时,发布一个OrderPaidEvent,状态机服务监听该事件并进行状态转换。
代码语言:txt
复制
public class Order {
    private OrderStateMachineService stateMachineService;

    public Order(OrderStateMachine症务Service stateMachineService) {
        this.stateMachineService = stateMachineService;
    }

    public void pay() {
        // 发布支付成功事件
        eventPublisher.publish(new OrderPaidEvent(this));
    }
}

public class OrderStateMachineService {
    @EventListener
    public void handleOrderPaidEvent(OrderPaidEvent event) {
        Order order = event.getOrder();
        transitionToPaid(order);
    }

    private void transitionToPaid(Order order) {
        // 状态转换逻辑
    }
}

参考链接

通过以上方法,可以在DDD和依赖注入的上下文中有效地管理实体的状态机,提高系统的可维护性和可扩展性。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

dotnet 通过依赖注入的 Scoped 给工作流注入相同的上下文信息

本文将来聊聊 Microsoft.Extensions.DependencyInjection 这个依赖注入框架的 Scoped 功能的一个应用,这个框架是默认 ASP.NET Core 的核心库将会默认被引用...Scoped 范围注入,那么此时在一次任务过程中,任务使用的步骤都在一个 Scoped 里面,如果此时的任务使用相同的类型的上下文信息类,那么此上下文信息将会是相同的对象。...string Id { set; get; } } 为了方便起见,我还是创建一个 ASP.NET Core 应用,因为这个应用框架默认部署好了依赖注入 在 Startup.cs 里面进行注册...F2 和 F3 的 Info 对象都是相同的对象,于是在 Info 对象设置的值可以在三个步骤使用 通过这个方法,在后续修改的时候,假如有一个信息是 F1 和 F3 都需要的,但是 F1 和 F3 是独立的...接着在 F1 和 F3 注入这个类,此时使用的对象就是相同的对象,因此参数也就能传递 有趣的是这个方法改动仅仅只是 F1 和 F3 两个类加上依赖注入构造,其他模块可以不动 本文代码放在 github

53710

Spring的控制反转和依赖注入

简单来说,就是处理对象的创建的、以及对象的依赖关系!...且可以很好的和其他框架一起使用,      如Spring和Hibernate,Spring和Struts2,其实通俗点讲Spring就是起到一种整合的作用,      如是一座桥梁,连接了Hibernate...和Struts2;   2.1:控制反转(Inversion of Confrol): 对象的创建交给外部容器完成,这个就叫做控制反转   2.2:依赖注入(dependency injection)...:      处理对象的依赖关系   2.3:控制反转和依赖注入的区别:      控制反转:解决对象创建的问题[对象创建交给别人即ioc容器];       依赖注入:在创建完对象后,对象的关系的处理就是依赖注入...[通过set方法依赖注入];   2.4:AOP面向切面编程     面向切面编程:切面,简单的说来可以理解为一个类,由很多重复代码形成的类。

763100
  • ddd中的子域和界限上下文 顶

    上下文的意思就是说一个概念在一个上下文中所关注的是一种意思,到了另一个上下文中所关注的是另一种意思。...任何互联网产品都会有用户这个概念,但是这个概念在不同的上下文中可能就完全不一样,比如买家和卖家就是在不同上下文中的意义。如果一个概念在两个子域中都一样,那就有可能这两个子域属于同一个上下文。...先来说一下一个概念在不同的子域属于不同上下文的例子,比如顾客在电商系统中,在购买时,可能表示的是他过往的购买记录,消费水平,折扣这些。而购买之后可能表示名字,地址,购买价格等等。...一般系统中都有用户和权限的东西,但这种东西在界限上下文中都可能在子域中与各种协作人员发生耦合。用户和权限与协作活动没有任何关系,并且与协作的通用语言也风马牛不相及。...在协作上下文中出现的每一种概念都必须与协作存在语言层面上的关联。我们应该关注的是协作概念,比如作者和主持者,这些才是协作活动中的正确概念和语言。

    1.1K50

    DDD-如何集成限界上下文和应用服务的使用

    JSON展现数据非常有用,但是当我们考虑到DDD的目标时,客户方的限界上下文是不会原封不动地消费这些JSON数据的。...在身份与访问上下文中,每一个订阅的租户都会创建2个Role实例:ScrumProductOwner和ScrumTeamMember。每一个需要 扮演某种角色的User都会被指派给相应的Role。...答案是否定的,因为如果我们使用过程中,事件消息的中间件出现了问题,我们又应该怎么办呢,这里比较通用的方法是:添加重试和超时机制1.3.4 长时处理过程的状态机和超时跟踪器创建一个TimeConstrainedProcessTracker...如果此时的消息消费方不能自动恢复,那么你需要确保重新注册该消费方。否则,你将发现你的限界上下文不再接收所依赖限界上下文发出的通知,这是你需要避免的。当然,问题并不总是出自消息机制。...其中,虚线表示的是依赖注入原则(4),而实线则表示操作分发。比如,基础设施实现了用户界面、应用服务和领域模型中的抽象接口,同时它还将操作分发给应用服务、领域模型和数据存储。

    1.6K00

    使用 IOC 控制反转和 DI 依赖注入的意义

    答案是不一定的,还有好多有趣的手段 那 DI 依赖注入和容器注入有什么关联?其实容器注入是依赖注入的一个核心方法,也就是现在用的最多的方法 那什么是容器注入呢?...其实容器注入相当于创建一个容器数组,然后当某个类需要依赖其他的类的时候,被依赖的类会提前放在容器里面,在被需要的时候从容器里面拿出来 还有一个问题是依赖注入是否和具体框架相关?用于解决什么问题?...上面这个是送命题…… 原因是难以有一个能说服大部分小伙伴的答案。我尝试回答第一个问题,尽管依赖注入和设计模式几乎是等同的概念,这仅仅只是一个通用的工程上的设计方案,和具体的产品或技术方案没有关系。...但是抛开具体的业务和技术方案讲依赖注入是十分空泛的而且几乎没有什么意义 那么 IOC 控制反转和 DI 依赖注入是想要解决什么问题?...,即使有再多的业务都不会让 元素加工厂 包含这部分的业务代码 其实上面的代码已经算是一个依赖注入容器了,同时实现的是属性注入的方式 回到开始的问题,请问依赖注入解决了什么问题?

    92110

    Quarkus中的依赖注入(DI)和aop编程(6)

    前言 做java开发的肯定清楚spring中的核心思想ioc和aop,ioc即控制反转的意思,di的核心思想和ioc一样,描述的也是同一个事情同一个思想,只是di的依赖注入更容易被理解了,aop即面向切面...绑定到生命周期上下文的有状态对象的定义良好的生命周期,其中上下文集是可扩展的 复杂的类型安全的依赖项注入机制,包括在开发或部署时选择依赖项的能力,而无需进行冗长的配置 支持Java EE模块化和Java...EE组件体系结构-解决Java EE组件之间的依赖关系时要考虑Java EE应用程序的模块化结构 与统一表达语言(EL)集成,允许在JSF或JSP页面中直接使用任何上下文对象 装饰注入对象的能力 通过类型安全的拦截器绑定将拦截器与对象相关联的能力...一个事件通知模型 除了Java Servlets规范定义的三个标准Web上下文之外的Web 对话上下文 允许便携式扩展与容器完美集成的SPI 通俗的说,JSR365是一套java实现DI依赖注入功能的接口设计...Quarkus中依赖注入和面向切面的基本使用方式和技巧,虽然没有spring的功能那么多那么细分。

    40840

    依赖注入和控制反转的理解,写的太好了

    1.3、IoC和DI DI—Dependency Injection,即“依赖注入”:组件之间依赖关系由容器在运行期决定,形象的说,即由容器动态的将某个依赖关系注入到组件之中。...:“依赖注入”,相对IoC 而言,“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。   ...控制反转) 和DI(依赖注入)中的每一个字,读完之后给人一种豁然开朗的感觉。...三、我对IoC(控制反转)和DI(依赖注入)的理解 在平时的java应用开发中,我们要实现某一个功能或者说是完成某个业务逻辑时至少需要两个或以上的对象来协作完成,在没有使用Spring的时候,每个对象在需要使用他的合作对象时...这是我对Spring的IoC(控制反转)的理解。DI(依赖注入)其实就是IOC的另外一种说法,DI是由Martin Fowler 在2004年初的一篇论文中首次提出的。他总结:控制的什么被反转了?

    62120

    Spring IoC容器的依赖注入1 getBean触发的依赖注入2. lazy-init属性和预实例化

    在Bean的创建和对象依赖注入的过程中,需要依据BeanDefinition中的信息来递归地完成依赖注入。...从前面的几个递归过程中可以看到,这些递归都是以getBean为入口 一个递归是在上下文中查找需要的Bean和创建Bean的递归调用 另一个递归是在依赖注入时,通过递归调用容器的getBean方法,得到当前...Bean的依赖Bean,同时也触发对依赖Bean的创建和注入。...在对Bean的属性进行依赖注入时,解析的过程也是一个递归的过程 这样,根据依赖关系,一层层地完成Bean的创建和注入,直到最后完成当前Bean的创建 有了这个顶层Bean的创建和对它属性依赖注入的完成...,意味着和当前Bean相关的整个依赖链的注入也就完成了 在Bean创建和依赖注入完成后,在容器中建立起一系列依靠依赖关系联系起来的Bean,这个Bean已经不再是简单的Java对象了。

    1.2K90

    对DDD(领域驱动设计)分层架构的理解(适合新人)

    ,聚合中其他实体或值对象依赖与聚合根。...只有聚合根才能被外部访问到,聚合根维护聚合的内部一致性。 9. 聚合根: 一个上下文内可能包含多个聚合,每个聚合都有一个根实体,叫做聚合根,一个聚合只有一个聚合根。 10....Repository项目依赖于Domain项目,Repository项目以依赖注入的方式,注入到领域层和应用层。...聚合根使用依赖注入动态注入Repository实现。因此,整个系统的依赖关系与高层架构设计吻合。...统一语言非常重要,每个概念在各自的上下文中是清晰的无歧义的,同时要控制领域模型的复杂度,于是 DDD 在战略上提出了分离子域(问题域空间)和拆分 BC(解决方案空间)的模式,BC 间通过 Context

    2K10

    Spring依赖注入的三种方式(好的 坏的和丑的)

    Spring开发者会很熟悉spring强大的依赖注入API,这些API可以让你用@Bean的注解让Spring实例化和管理Bean。Bean之间的任何依赖都会被spring解析和注入。...三种依赖于注解的注入方法   spring有三种注解的方式让你来声明类的依赖。...优点 最简洁 很多java开发者都喜欢这种方式 缺点 便利会弱化代码结构设计 很难测试 依赖不能是可变的(无法final) 容易出现循环依赖 需要使用到多个spring或者java注解 设值注入 模板和封装...缺点 违反开放封闭原则 会把循环依赖隐藏掉 三种方法里最模板化的方式 依赖不能是可变的(无法final) 终结方案:构造器注入   事实证明构造器注入是最佳的依赖注入解决方案。...构造函数需要下沉到子类 容易产生循环依赖 结论 构造器注入用起来吧   有时候其他模式也有意义,但“为了与代码库的其余部分保持一致”和“使用字段注入模式更简单”并不是有效的借口。

    1.9K10

    谈谈 Act 的依赖注入 和 模板输出 - 回答 drinkjava 同学提问

    其中需要使用对应与 User 实体类的 Dao. 在上面的代码中我们没有看到 userDao 是如何初始化的, 因为 userDao 是 Act 框架在实例化 UserService 的时候注入的....这就是一个典型的 Act 应用依赖注入的方式. 当然 Act 对于依赖注入的使用还有其他的扩展....Spring 的依赖注入至始至终都不是我的一个选项, 首先 Spring 的依赖注入不是 JSR 330 标准的实现, 另外 Spring 的依赖注入运行时效率太低 (参见依赖注入性能测试项目)....ActionContext 也是注入的对象. 2.1.3 依赖注入的扩展 II - 资源和配置参数注入 得益于 Genie 的扩展机制, Act 中可以很轻易地注入加载资源和配置参数. public static...可以看出依赖注入在这种场景的使用减少了 boilerplate 代码的使用, 让应用代码变得更加简洁易懂. 2.1.4 依赖注入机制总结 通过上面关于依赖注入机制的介绍, 可以看出依赖注入在 Act 应用中是基本的机制

    73320

    Go: 使用 github.comgooglewire 实现和管理复杂的依赖注入

    依赖注入(Dependency Injection, DI)是一种用于实现对象间依赖关系管理的设计模式。它通过将依赖项从类内部移到类的外部,来提升代码的可测试性、可维护性和灵活性。...简化依赖管理:自动生成依赖项的初始化代码,减少了手动编写的错误和复杂度。 易于集成:与现有的Go项目无缝集成,无需对现有代码进行大幅修改。...生成依赖注入代码:当我们运行wire命令时,Wire通过解析wire.Build参数中的构造函数了解依赖声明,并生成实际的依赖注入代码。...生成的代码类似于第二个函数,它会自动创建并注入所有声明的依赖项。 4....通过合理使用Google Wire,可以大幅简化依赖关系管理,使我们的Go项目更加模块化、易于维护和扩展。

    59410

    spring的ioc实现原理_ioc控制反转和di依赖注入

    大家好,我是架构君,一个会写代码吟诗的架构师。今天说一说spring的ioc实现原理_ioc控制反转和di依赖注入,希望能够帮助大家进步!!!...即软件系统中对象之间的耦合,对象A和对象B之间有关联,对象B又和对象C有依赖关系,这样对象和对象之间有着复杂的依赖关系,所以才有了控制反转这个理论。...,经过详细地分析和论证后,他得出了答案:“获得依赖对象的过程被反转了”。控制被反转之后,获得依赖对象的过程由自身管理对象变为由IoC容器主动注入。...(2).所谓依赖注入,就是由IoC容器在运行期间,动态地将某种依赖关系注入到对象之中。...(3).所以,依赖注入(DI)和控制反转(IoC)是从不同的角度描述的同一件事情,就是指通过引入IoC容器,利用依赖关系注入的方式,实现对象之间的解耦。

    47610

    精:理解和使用 .NET Core中依赖注入的作用域

    作用域是 .NET Core 依赖注入 (DI) 中的一个关键概念。它决定了注入到应用程序中的服务的生命周期和可见性。...理解作用域的工作原理可以帮助你更高效地管理资源,避免常见的陷阱,如内存泄漏和不必要的对象创建。本文将探讨什么是作用域、.NET Core 中可用的不同作用域类型,以及如何通过实际示例使用它们。...Singleton(单例) 单例服务在应用程序的整个生命周期中创建一次并共享。这适用于可共享的无状态服务。...总结 在 .NET Core 中理解并使用合适的服务作用域对资源管理和应用性能至关重要。...通过慎重选择合适的作用域,你可以优化应用程序的性能和可维护性。 希望这篇文章能帮助你理解 .NET Core 中的作用域概念及其有效的使用方法。如果你有任何疑问,请留言讨论!

    13410

    聊一聊状态机

    2.辅助领域模型设计 对于状态机出来说除了可降低领域专家和技术专家的沟通成本,并且在辅助领域模型设计方面还有以下几点帮助: 辅助实体设计:前面说到状态机在业务上的可以帮忙划清业务边界,而 DDD 里面分析清楚各个实体的业务边界是一个比较困难的事情...这个分析可能不会有每次都对,但是对新手刚开始使用 DDD 的时候对实体设计无从下手的时候是一个很好的设计思路 辅助领域事件设计:状态机除了了可以辅助实体设计,对领域事件的设计也是有帮助的。...其他设计方面的帮助:其他方面的话因为状态机可以让我们找到业务的实体,那么在设计的时候有时候不好区分的值对象和实体,在确认了实体以后,那剩下的应该就是值对象了。...还有就是在确认了实体和聚合根后,业务的界限上下文就清晰起来了,帮助界限上下文的划分。...3.做个小结 对于状态模式辅助 DDD 的设计这个方面来说,状态机的一些概念和 DDD 里面的一些概念是有些相似的。

    2.1K10

    深入理解 Spring IoC 和 DI:掌握控制反转和依赖注入的精髓

    在本文中,我们将介绍 IoC(控制反转)和 DI(依赖注入)的概念,以及如何在 Spring 框架中实现它们。 什么是控制反转?...控制反转是软件工程中的一个原则,它将对象或程序的某些部分的控制权转移给容器或框架。我们最常在面向对象编程的上下文中使用它。...:策略设计模式、服务定位器模式、工厂模式和依赖注入(DI)。...在 Spring 中,可以通过构造函数、setter 或字段来进行依赖注入。 基于构造函数的依赖注入 在基于构造函数的依赖注入的情况下,容器将调用具有表示我们要设置的依赖项的参数的构造函数。...结论 在本文中,我们介绍了控制反转和依赖注入的概念,并在 Spring 框架中进行了示例。

    58311

    【翻译】函数式编程中的领域驱动设计

    战略模式 vs 战术模式 战略模式 vs 战术模式 领域驱动设计(DDD)分为战略模式和战术模式。 战略模式由限界上下文、通用语言和上下文映射等模式组成; 战术模式由值类型、实体和聚合等模式组成。...它们主要涵盖更高级别的软件设计,例如有界上下文、上下文映射、反腐败层、有界上下文集成模式。 这些模式不依赖于所使用的编程语言或框架。 然而,战术模式依赖于编程语言结构和范式。...值类型和实体在函数时编程中的区别 经典的 DDD (面向对象的)实现基于它们的可变性和唯一性概念来区分值类型和实体类型。...Lens 允许您更新深度嵌套的值,并获取整个更新后的聚合。 使用 Monoid 来表示值对象:本文档很好地解释了 DDD 上下文中的 Monoid。 使用基于属性的测试来测试领域不变量。...如果想更炫,使用 Reader Monad 进行依赖注入。 通过遵循命令式外壳和函数式核心模式或使用 Free Monad,将副作用保持在边缘。

    1K20

    领域驱动设计案例之领域层框架搭建

    领域层框架搭建主要完成两个任务: 1.领域模型的建立,聚合与聚合根的确定,关系的确定。 2.建立支持DDD理论的领域层接口。 这里先上代码图,再详细讲每个部分的主要功能: ?...将IRepository接口定义在领域层的主要目的是:      1)领域层不应该直接依赖于仓储实现:如果领域层依赖于仓储实现,一是技术绑定太紧密,二是仓储要对领域对象作操作,会造成循环依赖。   ...2)将接口定义在领域层,减少技术架构依赖,应用层或领域层要使用某个仓储实现时,通过依赖注入的方式将仓储实现注射到应用层或领域层,具体IOC在使用时对应用层与领域层的建议见前面的文章。  ...通常我们的业务需要持久化整个聚合的多个实体或通过领域服务或应用服务持久化多个聚合,多个实体或聚合在业务上需要保持一致性,为了达到这个目的,我们引入了工作单元模式与定义了仓储上下文,通过仓储上下文来管理操作的多个实体或多个聚合中的实体...:IUnitOfWork,IDisposable { Guid ContextId { get; } /// /// 在事务上下文中标记聚合根为创建状态

    98770

    Dubbo源码篇08---依赖注入和AOP在Dubbo中的实现

    07—SPI神秘的面纱—原理篇—下 有了前面的铺垫,本文理解起来将会十分的轻松,对于依赖注入,我们首先想到的就是Spring中的@Autowired和@Resource注解,而AOP功能,则会首先联想到...所以对于Dubbo而言,其依赖注入和AOP也都是在其内部IOC基础上实现的,实现相比于Spring而言简单许多,所以废话不多说,我们直接开始Dubbo 依赖注入和AOP实现原理研究。...本文以普通扩展类的加载为总线,从使用层面验证之前原理篇中分析过的,关于依赖注入和Wrapper机制的代码。...---- 依赖注入 我们先来简单回顾一下依赖注入部分的源代码: createExtension方法是创建普通扩展类的核心方法: injectExtension依赖注入的核心代码如下所示:...为了防止我们自定义的ExtensionInjector把dubbo内部默认的依赖注入过程搅乱,需要通过注解打标记,限制我们自定义的ExtensionInjector所能处理的依赖注入范围: public

    55210

    「首席架构看领域驱动设计」领域驱动的设计和开发最佳实践

    这些文章讨论了DDD的主要元素,如实体、价值对象、服务等,或者讨论了泛在语言、有界上下文和反腐败层等概念。 本文的目标是从一个实际的角度来讨论如何获取域模型并实际实现它,从而涵盖域建模和设计。...另一方面,像JDBC驱动程序配置(驱动程序名、JDBC url、用户名和密码)这样的细节更适合存储在XML文件中,而不是使用注释。这是基于数据库在相同上下文中的假设。...在域建模的上下文中,实体、存储库和服务是使用注释的很好选择。 @ configured是Spring将存储库和服务注入域对象的方式。...上下文的特异性决定了域对象的协作以及其他运行时因素,如应用什么业务规则等。验证和其他业务规则总是在特定的业务上下文中处理。这意味着相同的域对象在不同的业务上下文中必须处理不同的业务规则集。...Eric Evans在他的书中谈到了CI,他说CI工作应该总是在有限的上下文中应用,它应该包括人和代码的同步。

    1.6K30
    领券