企业应用架构模式一

#目录

• 第一部分 表述
  • 分层
  • 组织领域逻辑
  • 映射到关系数据库
  • web表现层
  • 并发
  • 会话状态
  • 分布策略
  • 通盘考虑
• 第二部分 模式
  • 领域逻辑模式
  • 数据源架构模式
  • 对象-关系行为模式
  • 对象-关系结构模式
  • 对象-关系元数据模式
  • web表现模式
  • 分布模式
  • 离线并发模式
  • 会话状态模式
  • 基本模式

引言

架构是什么呢？

大众能够统一的定义有两点

• 最高层次的系统分解;
• 系统中不易改变的决定;

Ralph Johnson对架构的理解

• 一种主观上的东西，专家级项目开发成员对系统设计的一些可共享的理解—系统中主要的组成部分以及这些组成间的交互关系。
• 包含一些决定，开发者们认为难以改变的部分可以及早的作出。

Martin Flower在架构模式中最欣赏的就是“层次”。

模式？ 在我们周围不断重复发生的问题以及问题解决方案的核心。

第一章 分层

表现层：系统对外提供接口 领域层： 数据源层：系统使用外部服务的接口

如何区分什么是领域逻辑？ 不太正规的做法：想系统中增加一个完全不同的新层，例如为Web应用增加一个命令行界面层。如果在这个过程中，发现需要重复实现某些功能，则说明可能有一些本应该在领域层实现的逻辑，在表现层实现了。类似的也可以假想以下，后台数据库更换成XML文件格式，情况又会如何？

复杂性增压器（complexity booster）：分布、先是多线程、范型差异（例如对象/关系）。

第二章 组织领域逻辑

有三种模式

• 事务脚本：简单理解所有业务逻辑在一个函数里完成。包括数据转换、校验、事务、业务逻辑等。适合逻辑比较简单，未来变动不多的场景。
• 领域模型：开销大，来源于使用上、数据源层的复杂性。运用领域模型越充分，映射到关系数据库时就越复杂。
• 表模块：与领域模型很相似。关键区别，领域模型对于数据库中每一个模型都有一个相应的实例，而表模块只有一个公共的类实例和各个不同的数据集。

表模块是事务脚本和领域模型的一个中间地带。围绕表而非直接围绕过程来组织领域逻辑，提供了更多的结构。

专家只能推动你去思考，不能代替你去思考，所以不要让专家为自己的项目的架构设计提供建议和意见，单凭几分钟是不可能提出具体建议的。

第九章 领域逻辑模式

服务层

定义应用程序边界，建立一组可用的操作集合。封装了应用的业务逻辑、事务控制及其操作实现中的响应协调。

• 业务逻辑的种类 领域逻辑：至于问题领域有关，比如解决问题的策略、方式。 应用逻辑：又是也可以称为工作流逻辑。
• 实现方式 外观方法：领域模型之上的瘦外观模式实现。实现外观的类不包含任何业务逻辑，业务逻辑均由领域模型实现。 操作脚本：服务层由一组相对复杂的类组成。类直接实现应用逻辑，但将领域逻辑猥琐给封装好的领域对象类。
• 是否远程 由于接口粒度粗，适合于远程调用。远程调用的代价在于对象分布性的处理，在‘服务层’方法标记中处理‘数据传输对象’，需要许多额外的工作。尤其是一个复杂的领域模型是，工作量不要低估；而且对那些复杂的更新用例有大量编辑界面时。代价和痛苦程度仅次于对象到关系数据库的映射。
  • 建议分为本地调用的服务层+远程外观层。本地服务层仅处理领域对象，需要远程调用功能时，在服务层之上增加一个远程外观来实现，或者让你的服务层对象实现远程接口。
• 识别服务与操作 根据领域模型的划分来抽象，ContractService，ProductService；或更具应用程序的行为主题来抽象RecognitionService
• 适用场景 预见到第二种客户，或用例响应中多于一个事务性资源。