领域驱动设计与模型驱动开发
《领域驱动设计》基础知识汇总
《领域驱动设计》基础知识汇总《领域驱动设计》（Domain-Driven Design，简称DDD）是一种软件开发方法论，它将软件开发过程中的关注点从技术细节转移到业务领域上。
DDD强调将业务需求和软件模型紧密对应，以便更好地理解业务需求，并将其准确地转化为可执行的软件模型。
以下是《领域驱动设计》的基础知识汇总。
1.领域驱动设计的核心思想是通过将知识转化为模型来解决复杂问题。
领域模型是对业务领域知识的抽象和表达，它将业务对象、业务规则和业务流程等概念化地表示出来。
2.领域驱动设计强调领域专家参与，并与开发团队紧密合作。
领域专家是对业务领域非常熟悉的人，他们能够提供与业务相关的知识和经验，并对软件开发过程中的需求和模型进行指导。
3.领域驱动设计提倡使用统一的语言来描述业务领域。
该语言应该由领域专家和开发团队共同创造，以最大程度地减少沟通障碍并提高开发效率。
4.领域驱动设计中的聚合是一个非常重要的概念。
聚合是一个具有内聚性的对象集合，它们被视为一个整体并按照一定的规则进行操作和管理。
聚合根是聚合中最核心的对象，它负责管理整个聚合的状态和行为。
5.领域驱动设计中的领域事件是一种重要的机制，用于解耦和通信。
领域事件是业务领域中发生的一些关键事件，它们被抽象为领域事件，并且可以被其他对象订阅和处理。
6.领域驱动设计中的领域服务是一种封装了业务逻辑的对象，它不属于任何聚合和实体，负责处理那些跨聚合的复杂业务逻辑。
领域服务可以与其他对象进行协作，但它不应该持有状态。
7.领域驱动设计中的领域模型需要经过持久化以便在不同的系统之间共享和使用。
领域模型可以通过使用ORM框架或其他数据持久化技术来实现，并根据需要进行优化。
8.领域驱动设计强调使用领域驱动设计模式来解决常见的设计问题。
这些模式包括实体、值对象、仓储、工厂、规范等，它们提供了一些通用的解决方案，可以帮助开发人员更好地组织和管理领域模型。
9.领域驱动设计需要采用迭代增量的方式进行开发，将复杂的需求拆分成小的任务，并通过测试驱动开发的方式逐步实现。
领域驱动设计与模型驱动开发
在系统测试过程中，如果发现异常或错误，可以根据领域模型快速定位问题所在，提高 故障排查的效率。
04
领域驱动设计与模型驱动开发 的应用场景
领域驱动设计在金融领域的应用
总结词
领域驱动设计在金融领域的应用主要体现在业务逻辑的模块化划分和抽象上，有助于提高系统的可维护性和可扩 展性。
持续进化
01
领域驱动设计将进一步进化，以更好地适应业务需求的变化。
微服务化
02
随着微服务架构的普及，领域驱动设计将更加注重服务间的边
界划分和交互。
强化数据建模
03
领域驱动设计将更加注重数据建模，以提升数据的一致性和完
整性。
模型驱动开发的未来发展方向
01
智能化
模型驱动开发将借助人工智能和 机器学习技术，实现开发过程的 智能化。
模型驱动开发的主要技术
统一建模语言（UML）
UML是一种用于描述、设计和实现软件系统的图形化建模语言， 是模型驱动开发的核心技术之一。
模型转换技术
模型转换技术是模型驱动开发中的一项关键技术，它可以将一种模 型转换为另一种模型，从而实现模型的自动生成和转换。
模Hale Waihona Puke 验证技术模型验证技术是用于检查模型是否符合规范和要求的一种技术，可 以及早发现和修复错误。
定义领域的边界，明确各部分的职 责和交互方式。
迭代和增量开发
逐步完善领域模型，通过迭代方式 实现软件的开发和演化。
04
02 模型驱动开发
模型驱动开发的基本概念
模型驱动开发（Model-Driven Development，简称MDD）是一种软件开发方法论，它强调使用统一建 模语言（Unified Modeling Language，简称UML）等建模工具来描述、设计和实现软件系统。
模型在领域驱动设计中的作用
模型在领域驱动设计中的作用领域驱动设计(Domain-Driven Design, DDD)是一种软件开发方法论，旨在通过将软件系统的设计与相关领域的知识相结合，提供高质量的软件解决方案。
在领域驱动设计中，模型扮演着至关重要的角色。
模型是对领域知识的抽象和表达，是开发团队和业务专家之间的共同语言，能够帮助开发团队更好地理解和应对复杂的业务需求。
模型在领域驱动设计中起到了沟通的作用。
由于领域驱动设计强调开发团队和业务专家之间的合作，模型作为双方共同的语言，能够帮助双方更好地理解和交流。
通过模型的建立和迭代，开发团队可以更准确地捕捉业务需求，并将其转化为可执行的软件解决方案。
同时，模型也能够帮助业务专家理解软件系统的设计和实现过程，提供反馈和指导，使开发团队能够更好地满足业务需求。
模型在领域驱动设计中起到了设计的作用。
在领域驱动设计中，模型是对领域知识的抽象和表达，通过模型的建立和演化，开发团队能够更好地理解和分析业务领域的复杂性。
模型可以帮助开发团队识别出领域中的重要概念和关系，并将其转化为软件系统的设计元素。
通过模型的建立和迭代，开发团队能够更好地理解业务需求，设计出更合理、可扩展和可维护的软件架构。
模型在领域驱动设计中起到了验证的作用。
模型是对领域知识的抽象和表达，通过模型的建立和演化，开发团队能够更好地验证软件系统是否满足业务需求。
模型可以作为开发团队和业务专家之间的共同语言，通过对模型的讨论和验证，开发团队能够更准确地理解业务需求，并将其转化为可执行的软件解决方案。
通过模型的验证，开发团队能够及时发现和解决潜在的问题，提高软件系统的质量和稳定性。
模型在领域驱动设计中起到了演化的作用。
在领域驱动设计中，模型是一个持续演化的过程，随着业务需求的变化和发展，模型也需要不断地迭代和完善。
通过模型的演化，开发团队能够更好地理解业务需求的变化，并将其转化为可执行的软件解决方案。
模型的演化能够帮助开发团队适应变化，保持软件系统的灵活性和可扩展性。
领域驱动设计详解
领域驱动设计详解领域驱动设计（Domain-Driven Design，DDD）是一种软件开发方法论，旨在解决复杂领域中的问题。
它强调软件开发应该以领域为核心，将领域专家的知识融入到设计中，以便更好地理解和解决领域中的问题。
在领域驱动设计中，领域是指问题领域的具体范围，例如电子商务、银行业务等。
领域专家是在该领域中具备丰富知识和经验的人员。
通过与领域专家的密切合作，开发团队可以更好地理解和解决问题。
领域驱动设计的核心概念包括领域模型、限界上下文和聚合根。
领域模型是对领域的抽象和描述，它包含了领域中的实体、值对象、服务和领域事件等。
领域模型应该是由领域专家和开发团队共同定义和演化的，以确保模型能够准确地反映领域的实际情况。
限界上下文是指领域模型的边界，它定义了在不同上下文中的含义和范围。
一个限界上下文可以是一个子系统、一个模块或一个服务，它负责管理自己的领域模型和业务逻辑。
通过明确限界上下文，可以确保不同上下文之间的交互和协作更加清晰和有效。
聚合根是领域模型中的重要概念，它是一组相关对象的根节点。
聚合根负责维护聚合内部的一致性和完整性，并且提供了访问和操作聚合内部对象的接口。
通过聚合根，可以将复杂的领域模型分解为更小的组件，提高系统的可维护性和灵活性。
在实施领域驱动设计时，需要遵循一些基本原则和模式。
要尽量保持领域模型的简洁和清晰。
领域模型应该只包含与领域相关的概念和逻辑，避免引入与领域无关的技术细节。
同时，要注重模型的可复用性和可扩展性，以便应对未来的需求变化。
要进行持续的领域建模和迭代开发。
领域模型应该是一个持续演化的过程，通过与领域专家的交流和反馈，不断优化和完善模型。
同时，要采用敏捷开发的方法，以快速响应需求变化，并及时调整和修改领域模型。
要注重领域模型和代码的质量。
领域模型应该是可测试和可验证的，以确保模型的正确性和一致性。
同时，要采用合适的设计模式和技术，以提高代码的可读性、可维护性和可扩展性。
ddd的设计方法
ddd的设计方法DDD（领域驱动设计）是一种软件设计方法，主要关注领域模型的设计和领域驱动设计原则的应用。
它强调软件设计应该反映领域模型，并将其作为核心设计元素。
在DDD中，领域模型是对业务领域的概念和规则的映射，它封装了业务逻辑和数据访问。
DDD的设计方法可以分为下面几个方面：1.领域驱动设计原则：DDD倡导将领域模型作为核心设计元素，通过使用领域模型中的领域对象、值对象和领域服务来解决问题。
此外，DDD还强调通过领域事件和领域服务来处理业务逻辑。
2.领域模型的定义：在DDD中，领域模型是对业务领域的概念和规则的映射。
通过定义领域对象（实体）、值对象和领域服务，可以捕获业务问题的本质，并将其转化为软件设计中的类和接口。
3.聚合根和聚合：聚合是领域模型中的一个重要概念，用于定义一组相关的领域对象。
聚合根是聚合中的一个特殊对象，它负责维护聚合内部对象的一致性和完整性。
通过定义聚合和聚合根，可以将复杂的业务逻辑分解为更小的单元，并实现领域驱动设计的分层结构。
4.领域事件和事件驱动架构：DDD强调使用领域事件来处理业务逻辑。
领域事件是对领域中重要的状态变化或行为的抽象，它可以用于实现事件驱动架构（EDA）和异步通信。
通过定义领域事件，可以实现领域模型的解耦和灵活性。
5.领域驱动设计的分层架构：DDD倡导将领域模型分离开来，使其成为应用程序的核心。
通过使用领域层、应用层和基础设施层，可以实现业务逻辑和技术实现的解耦。
领域层负责实现领域模型和业务规则，应用层提供应用程序的基本逻辑，基础设施层则负责与外部系统的交互。
6.测试和演进式设计：DDD强调测试驱动开发（TDD）和迭代开发，以确保软件设计的可测试性和灵活性。
通过高度可测试的领域模型和领域服务，可以实现单元测试、集成测试和端到端测试，并支持持续集成和发布。
7.组织和沟通：在DDD中，软件设计师需要与领域专家密切合作，共同开发和验证领域模型。
通过领域驱动设计的方法，可以促进软件团队内部以及与领域专家之间的有效沟通和协作。
DDD—什么是领域驱动设计
DDD—什么是领域驱动设计领域驱动设计（Domain-Driven Design，简称DDD）是一种软件开发方法论，强调将对领域的理解和业务需求置于软件设计和开发的核心位置。
领域驱动设计的目标是通过充分理解和建模领域，实现软件系统与业务领域的高度一致性，并提高软件开发的效率和质量。
在领域驱动设计中，核心思想是将软件系统设计为由领域模型（Domain Model）驱动的系统。
领域模型是对业务领域的抽象和概念化，它反映了问题领域的核心概念、业务规则和关键流程。
通过领域模型的建立，可以更好地理解和表达业务需求，为软件开发提供明确的指导和依据。
在领域驱动设计中，首要任务是对领域进行深入了解和分析，通过与领域专家的合作，获取对领域的深入理解、业务需求和规则。
这种合作被称为“域（Domain）专家与开发者的沟通”，其中域专家负责提供业务知识，开发者则负责将其转化为可执行的软件系统。
通过这种方式，在设计和开发过程中避免了沟通和理解上的困境，确保软件系统与业务领域的一致性。
领域驱动设计强调使用领域通用语言（Ubiquitous Language）来沟通和建模。
通用语言是一套在整个软件系统中通用的、与业务相关的术语和概念。
通过使用通用语言，可以将业务需求和软件设计紧密结合起来，避免语义模糊和沟通误解。
在领域驱动设计中，领域模型是实现领域驱动设计的核心工具。
领域模型是对业务领域的抽象和建模，它由实体（Entity）、值对象（Value Object）、领域服务（Domain Service）等元素组成。
领域模型制定了业务领域的规则、行为和状态，并提供了对业务需求的有效表达和实现。
通过将领域模型转化为代码，可以建立高度一致的软件系统。
除了领域模型，领域驱动设计中还涉及到一些核心概念和模式，如聚合（Aggregate）、工厂（Factory）、仓储（Repository）、领域事件（Domain Event）等。
这些概念和模式为领域驱动设计提供了更加灵活和可扩展的开发框架，使得软件开发更加贴合业务需求。
领域驱动设计详解
领域驱动设计详解领域驱动设计(Domain-Driven Design，简称DDD)是一种软件开发方法，旨在帮助解决复杂领域的设计和开发问题。
它强调以领域为核心，通过深入理解领域知识和业务规则，将软件设计与领域模型紧密结合，从而提高软件系统的质量和可维护性。
1. 为什么需要领域驱动设计？在传统的软件开发中，往往将重点放在技术层面，而忽略了对领域知识的深入理解。
这导致了软件系统与实际业务需求之间的脱节，使得软件难以满足用户的真正需求。
而领域驱动设计的出现正是为了解决这个问题。
它通过将业务专家、开发人员和设计人员紧密合作，共同创建一个清晰的领域模型，以满足业务需求并提高软件质量。
2. 领域模型的核心概念在领域驱动设计中，领域模型是核心概念之一。
领域模型是对业务领域的抽象和描述，它包含了实体、值对象、聚合根、领域服务等元素。
实体是具有唯一标识的对象，值对象是没有唯一标识的对象，聚合根是一组相关对象的根，领域服务是领域模型中的动作和操作。
通过定义和使用这些元素，可以更好地表达业务需求，并将其映射到软件系统中。
3. 领域驱动设计的核心原则领域驱动设计有一些核心原则，包括战略设计和战术设计。
战略设计关注的是领域模型的整体结构和组织，它主要包括限界上下文、通用语言等概念。
限界上下文是指将整个领域划分为不同的上下文边界，每个上下文都有自己的领域模型和业务规则。
通用语言是指在领域专家和开发人员之间建立共同的语言，以便更好地沟通和理解业务需求。
4. 领域驱动设计的实施过程领域驱动设计的实施过程通常包括以下几个步骤：- 深入理解业务需求：与领域专家进行密切合作，了解业务规则和需求，形成共同的理解。
- 创建领域模型：根据业务需求，定义领域模型的各个元素，包括实体、值对象、聚合根、领域服务等。
- 持续迭代和优化：根据实际情况，不断迭代和优化领域模型，以适应业务的变化和发展。
- 划分限界上下文：将整个领域划分为不同的上下文边界，每个上下文都有自己的领域模型和业务规则。
软件架构中的领域驱动设计(DDD)
软件架构中的领域驱动设计(DDD)领域驱动设计(DDD)是一种软件开发方法论，它将软件项目的设计和实现过程，建立在对业务领域的深入理解基础之上。
通过将业务领域的知识和经验融入到软件设计和开发的过程中，DDD可以帮助开发团队更好地理解业务需求，提高软件的质量和稳定性。
1. DDD的基本概念领域驱动设计的核心思想是将软件系统划分为不同的领域，每个领域都有自己的业务模型、规则和流程。
通过深入了解这些领域的特点和要求，开发团队可以设计出更加贴合实际需求的软件架构和系统设计。
在领域驱动设计中，通常会使用领域模型、领域事件和领域服务等概念，来帮助团队更好地理解和实现业务需求。
2. DDD的核心概念2.1领域模型领域模型是领域驱动设计的核心概念，它是对领域中各种实体、值对象、聚合和领域服务等概念的抽象和建模。
通过领域模型的建立，开发团队可以更好地理解业务逻辑和规则，从而设计出更加贴合实际需求的软件系统。
领域模型通常是通过领域专家和开发团队的合作来构建的，它是对业务需求的一种抽象和概括。
2.2领域事件领域事件是领域驱动设计中的另一个核心概念，它是描述领域中事件发生和影响的概念。
通过将领域中的各种事件进行抽象和建模，开发团队可以更好地理解各种业务规则和流程，从而设计出更加稳定和可靠的软件系统。
领域事件通常是领域模型的一部分，它描述了业务领域中的各种重要事件和影响。
2.3领域服务领域服务是领域驱动设计中的另一个重要概念，它是对业务领域中某些重要操作和逻辑的抽象和建模。
通过领域服务，开发团队可以更好地处理各种业务逻辑和操作，从而设计出更加灵活和可扩展的软件系统。
领域服务通常是领域模型的一部分，它描述了业务领域中的各种重要操作和逻辑。
3. DDD的应用实践在日常的软件开发过程中，领域驱动设计可以帮助开发团队更好地理解和实现业务需求，提高软件系统的质量和稳定性。
在应用领域驱动设计的实践中，通常会涉及到以下几个方面的工作：3.1领域分析和建模领域分析和建模是领域驱动设计的重要环节，它通过与业务专家的沟通和合作，来深入了解业务领域的特点和要求，从而建立起相应的领域模型、领域事件和领域服务等概念。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
使用通用语言的重要性
Talking different languages makes projects fail.
Programmers speak using technical jargon (design patterns, acronyms, geeky in-jokes) Domain experts use terminology specific to their field of expertise Computers speak programming languages 大家必须妥协
致谢：
此培训材料借鉴了来自参考文献以及互联网的大量资料，部分资料的参 考来源未能尽数列举，谨在此对那些在网络中无私分享自己知识的人表达我 的衷心感谢！
培训内容
领域驱动设计简介 领域通用语言 领域驱动设计的构造块 领域驱动设计编程实践 CQRS架构 模型驱动开发
领域驱动设计思想的发展
2002年Martin Fower在其出版《企业应用架构模式》中，归纳总结了40 多种企业应用架构的设计模式。其中所提到的多种设计模式和概念，如事 务脚本、活动记录和领域模型等，对业界产生了深远的影响。
领域驱动设计的一个核心思想就是使用基于模型的共同语言。因为模型是软件满足领域的共同点，它很适合
作为这种通用语言的构造基础。使用模型作为语言的核心骨架，要求团队在进行所有的交流都是使用一致的 语言，在代码中也是这样。在共享知识和推敲模型时，团队会使用语言、文字和图形。这儿需要确保团队使 用的语言在所有的交流形式中看上去都是一致的，这种语言被称为“通用语言（Ubiquitous Language）”。
对类的策略和类型的划分
按照策略和类型对类进行划分
对类进行StereoType(“构造型”)划分的好处在于： （1）指导设计 （2）帮助命令对象 （3）辅助理解
六边形架构
以领域模型为核心的六边形架构
领域驱动设计中的设计模式
有助于获得柔性设计的设计模式
任何对未来操作产生影响的系统 状态的改变都可以成为副作用。 把命令和查询严格地放到不同操 作中；创建并返回Value Object。 允许我们安全地对多个操作进行 组合。 使用断言把副作用明 确表示出来，使它们 更易于处理。 寻找在概念上内聚的 模型，更易推出预期 ASSERTION，从而加 快学习过程并避免代 码矛盾。
通用语言的词汇表包括类名称和主要操作。语言中包含术语，有些术语用来讨论模型中已经明确的规则，还 有一些术语则来自施加于模型上的高级组织原则。最后，团队一致应用于领域模型的模式名称使这种语言更 为丰富。模型之间的关系成为所有语言都具有的组合规则，词和短语的意义反映了模型的语义。
通用语言（二）
在应用通用语言时，应注意：
通用语言是那些不以代码形式出现的设计方面的主要载体，这些方面包括 把整个系统组织在一起的比例结构、定义了不同系统和模型之间关系的 Bounded Context，以及在模型和设计中使用的其他模式。
通用语言的应用
通用语言贯穿于项目的各个环节
User Stories Project Meetings Team Emails Instant Messages Schedule Plan Software Documents
每个元素的名称都提供 了一次揭示设计意图的 机会。站在客户开发人 员的角度上来思考它。
操作闭合：在适当的情况下，在 定义操作时让它的返回类型与其 参数相同。闭合操作提供了一个 高层接口，同时又不会引入对其 他概念的任何依赖性。
人们为了使所有类和操作都具有相似的规模 而寻找一种一致的力度。粒度的大小并不是 唯一要考虑的问题，我们还要考虑粒度在哪 种场合下使用。 随着代码重构不断适合新理解的概念或需求， 概念轮廓也就逐渐形成了。搞内聚低耦合原 则既适用于代码，也适用于概念。
ቤተ መጻሕፍቲ ባይዱ
领域驱动设计的特性
分层架构 • 成熟、清晰的分层架构 • 领域对象与现实世界的业务映射 • 明确的职责划分 复用 • 领域对象是核心 • 领域对象复用：完整的业务对象描述 • 设计复用：设计基于领域对象而非数据库 使用场景
• 具备复杂业务逻辑的软件开发 • 对设计和开发人员要求较高 • 不适用普通CRUD的业务 • 软件的维护性和扩展性良好 (Testable)
领域驱动设计分层规划（一）
领域驱动设计分层规划
用户界面/ 负责向用户展现信息以及解释用户命令。 展示层的组件实现用户与应用交互的功能。 展现层
一般建议用MVC，MVP或者MVVM模式来 分隔这些组件为子层
应用层
很薄的一层，用来协调应用的活动，实现 协调应用的“通道”，例如事务、执行单 位操作、调用应用程序的任务。它不包含 业务逻辑。它不保留业务对象的状态，但 它保有应用任务的进度状态。 类似于Façade模式，调用领域层和基础设 施层来完成应用的用例。 本层包含关于领域的信息。这是业务软件 的核心所在。在这里保留业务对象的状态， 对业务对象和它们状态的持久化被委托给 了基础设施层。 本层作为其他层的支撑库存在。它提供了 层间的通信，实现对业务对象的持久化， 包含对用户界面层的支撑库等作用。
It’s a set of principles and practices supporting the development process.
It’s a set of patterns that support a clean and coherent view of the domain model. It’s a set of pragmatic strategies allowing applications to scale in size and complexity maintaining their integrity.
在限界上下文中，保持语言的一致性（如口语、图形（如UML图等）、文 字、代码等）。
通用语言的应用示例（一）
User Stories
NO
When User logs on with valid credentials, an empty panel is displayed.
YES
When Player logs on with valid credentials, an empty board game is displayed.
将模型作为语言的中心。确保团队在所有交流活动和代码中坚持使用这种语言。 在画图、写东西特别是讲话时也要使用这种语言。 通过尝试不同的表示方法（它们反映了不同模型）来消除难点。然后重构代码， 并对类、方法和模块重新命名，以便与新模型相一致。解决交谈中的术语混淆
问题，就像我们对普通词汇形成一个公认的理解一样。
领域驱动设计是什么
领域驱动设计事实上针对是OOAD的一个扩展和延伸，DDD基于面向对 象分析与设计技术，对技术框架进行了分层规划，同时对每个类进行了策 略和类型的划分。
It’s a set of proven modeling techniques especially targeted to complex applications.
尽一切可能保持低耦合。把所有无关概念提取到 对象之外，类就变成完全孤立的了，使得我们可 以单独地研究和理解它。每个孤立类都极大减轻 了因理解Module而带来的负担。
《领域驱动设计—软件核心复杂性应对之道》第10章
培训内容
领域驱动设计简介 领域通用语言 领域驱动设计的构造块 领域驱动设计编程实践 CQRS架构 模型驱动开发
2004年著名建模专家Eric Evans发表了他最具影响力的著名书籍： 《Domain-Driven Design –Tackling Complexity in the Heart of Software》（中文译名：领域驱动设计—软件核心复杂性应对之道）， 书中提出了“领域驱动设计(简称DDD)”的概念。 2010年Greg Young在“CQRS, Task Based UIs, Event Sourcing agh! ” 一文中对Betrand Meyer的CQS模式进行改造，提出CQRS模式。 此后Jimmy Nilsson的《Applying Domain-Driven Design and Patterns》、Abel Avram和Floyd Marinescu合作的《Domain-Driven Design Quickly》、Dan Haywood的《Domain-Driven Design Using Naked Objects》、以及Vaughn Vernon的《Implementing DomainDriven Design》等书籍的出版，丰富了领域驱动设计的实践和指导。
《Core J2EE Patterns》
领域驱动设计分层规划（四）
分布式领域驱动设计
领域驱动设计分层规划（五）
分布式领域驱动设计与DotNET技术架构体系之间的关系映射
面向对象分析与设计技术
面向过程vs.面向对象
事务脚本模式把业务逻辑组织成单个过程，在过程中直接调用数据库，业务逻辑在服务(Service)层 处理。 事务脚本模式的特点是简单容易理解，面向过程设计。对于少量逻辑的业务应用来说，事务脚本 模式简单自然，性能良好，容易理解，而且一个事务的处理不会影响其他事务。 不过缺点也很明显，对于复杂的业务逻辑处理力不从心，难以保持良好的设计，事务之间的冗余 代码不断增多，通过复制粘贴方式进行复用。可维护性和扩展性变差。
领域层
基础设施 层
领域驱动设计分层规划（二）
领域驱动设计是对传统N层架构模式的继承和发展
领域驱动设计分层规划（三）
领域驱动设计是对传统N层架构模式的继承和发展
例：J2EE参考分层架构