WebService基础教程带实例08.领域模型驱动设计3.pptVIP

Facade 实践Facade的过程中最难把握的问题就是Facade的粒度问题。 传统的Service均以实体为单位进行组织，而Facade应该具有更粗粒度的组织依据，较为合适的粒度依据有： 一个高度内聚的模块一个Facade 或者是一个“聚合”(特指领域驱动设计)一个Facade. DDD SOA DDD 领域模型驱动设计 SOA 面向服务的架构 本课程版权归北风网所有 欢迎访问我们的官方网站 基于面向对象技术设计的领域对象（即通常所说的“实体”）都是细粒度的，将细粒度的领域对象直接传递到远程调用端需要进行多次网络通信，DTO在设计之初的主要考量是以粗粒度的数据结构减少网络通信并简化调用接口 * 介绍一层提供服务的远程客户 ?暴露了一个统一的粗粒度接口 ?降低耦合层之间 ?促进分层，增加灵活性和可维护性 ?降低复杂性 ?提高性能，降低细粒度的遥控方法 ?集中安全管理 ?集中交易控制 ?暴露了更少的远程接口，客户 * Service的接口是面向用例设计的，是控制事务、安全的适宜场所。如果Fa?ade的某一方法需要调用两个以上的Service方法，需要注意事务问题。 * 有一些系统使用反射机制自动实现DTO与领域对象之间的相互转换，Appache的Commons BeanUtils就提供了类似的功能 应该说这两种实现各有利弊，使用Assembler进行对象数据交换更为安全与可控，并且接受编译期检查，但是代码量明显偏多。 使用反射机制自动进行象数据交换虽然代码量很少，但却是非常脆弱的，一旦对象属性名发生了变化，数据交互就会失败，并且很难追踪发现。 总体来说，Assembler更为直白和稳妥。 Transaction Script风格的架构具有明显的“数据”与“操作”分离的特征，其和领域驱动设计风格的架构在两个类组件上有质的区别，一个是领域对象，一个是Service。领域驱动设计的架构核心目标是要创建一个富领域模型，其典型特征是它的领域对象具有丰富的业务方法用以处理业务逻辑，而Transaction Script风格的领域对象则仅仅是数据的载体，没有业务方法，这种领域也被称作“贫血的领域对象”(Anemic Domain Objects)。在Service方面，领域驱动设计的架构里Service是非常“薄“的一层，其并不负责处理业务逻辑，而在TransactionScript风格的架构里，Service是处理业务逻辑的主要场所，因而往往非常厚重。 Application层中主要组件就是Service,在领域驱动设计的架构里，Service的组织粒度和接口设计依据与传统Transaction Script风格的Service是一致的，但是两者的实现却有着质的区别。TransactionScript风格的Service是实现业务逻辑的主要场所，因此往往非常厚重。而在领域驱动设计的架构里，Application是非常“薄”的一层，所有的Service只负责协调并委派业务逻辑给领域对象进行处理，其本身并真正实现业务逻辑，绝大部分的业务逻辑都由领域对象承载和实现了，这是区别系统是Transaction Script架构还是Domain Model架构的重要标志。 * 整个应用程式层是负责驱动工作流的应用程序，相匹配的情况下，在手。这些操作是独立于接口的andcan同步或消息驱动。这一层是非常适合forspanning交易，高层次的记录和安全。应用程序在域逻辑layeris薄的 - 它只是负责协调在的域名layerobjects到执行实际的工作。 不管是Transaction Script风格还Domain Model风格， 除了三个垂直层，也有基础设施。作为这个图片显示，它支持所有的三层不同的方式，促进沟通的层。简单来说，基础设施包括一切存在独立于我们的应用：外部库，数据库，应用服务器后端，通讯等。 此外，我们考虑的代码和配置文件，其他层的基础设施的一部分，基础设施层。例如看看hibernate方面，数据库模式定义，配置和绘图文件和实现的库接口部分基础设施层。 虽然很难给了坚实的定义什么类型的代码是属于基础设施层在任何给定的情况下，它应该能够完全存根基础设施在纯粹的爪哇单位/情景测试却依然能够使用领域层和应用层的可能发展出企业的核心问题。 架构概述 详细架构 架构详解:Interfaces-接口层 该层包含与其他系统进行交互的接口与通信设施，在多数应用里 可能提供包括Web Services、RMI或Rest等在内的一种或多种通信接口 该层主要由Facade、DTO和Assembler三类组件构成，三类组件均是典型的J2EE模式 DTO DTO- DataTransfer Object（数据传输对