ABD—— 基于架构的开发模式上海湃睿信息科技有限公司 Bardo QI ( 祁宏 )

2010 年 7 月 30 日

© 2010 PISX 2

概要 ABD—— 基于架构的开发模式，在微软， ADOBE 等公司中被

使用，在 ACTIONSCRIPT ， JAVA 语言中作用非凡。奇怪的是在 PHP 界却相当落后。

有人说，掌握了 ABD ，就能够轻松项目管理，掌握了 ABD，就离真正的架构师不远了。那么，你想了解 ABD 吗？

本话题为你揭开基于架构的开发模式的秘密，解决代码可读性，可维护性，可扩展性，与程序员的无关性等问题，使你的项目管理技术更上一层楼，让你走上架构师之路。

© 2010 PISX 3

两种截然不同的结果

我们最不想要的 我们最想要的

有极为详细的《编程规范》却代码仍不规范

用最简的《编程规范》，但代码仍相当规范

代码不具有可读性，与程序员无关性差。 代码可读性高，与程序员无关性高。

程序员风格对程序结构存在较大的影响。结伴编程，仍是正草隶篆。

程序员风格对程序结构的影响力几乎为零。独立开发，团队如同一人。

高手，新人，质量相距甚远 抄袭，原创，结果只有一个

应用越是庞大，架构是越是混乱 无论大小，架构永远不变

有多少个应用，就有多少种架构 统一标准的架构，人人清楚哪个目录是什么，每一个源码文件都是 class

…… ……

© 2010 PISX 4

什么是软件开发模式 软件开发模式的定义包含两方面：

其一是指软件开发中的管理模式，即在软件开发过程中要管理什么，怎样管理。

其二是指软件开发中的操作规范，包括开发流程定义，即按照什么样的步骤来开发软件。

有了敏捷，真的还会这么痛苦吗？ 本主题阐述软件开发模式与架构管理模式之间的关系。并以 PHP 应

用架构管理为中心，讲述架构管理的沿革， PHP 架构管理现状，以及架构管理中一些必要的原则、 PHP 大型应用的基本架构等。

时间有限，内容太多，无法进行实例讲解，敬请谅解！

© 2010 PISX 5

新型软件开发模式简介 SCRUM 由 Ken Schwaber 和 Jeff Sutherland 提出和倡导

敏捷开发模式 sprints 短周期循环， scrum 会议，以及 burn down graph 管理

XP (eXtreme Programming) 由 Kent Beck,Ward Cunningham,Ron Jeffries 提出和倡导 TDD 与连续性整合 结伴编码

ASD （ Adaptive Software Development）由 Jim Highsmith 提出和倡导 speculate,collaborate,and learn（将项目的历程分成 3 个阶段：思索、合作、学习

TimeBoxed 时间盒管理 MSF(Microsoft Solutions Framework) 由 Randy Miller,Paul Haynes 提出，微

软倡导 使用者角色 (Personals)推行一个从角色到使用方案的设计流程 单元测试

© 2010 PISX 6

软件开发模式是否足够？ “新型”开发模式普遍被接受并广应用：

基于测试的开发（ TDD）• 先确定测试，以测试为中心。

敏捷开发模式• 如前述的 SCRUM ， XP 开发模式

代码制质量控制：• code review• 结伴编程

PHP 使用“新型”开发模式产出的软件？ BUG依旧 可靠性仍然很差 最后期限仍不可预估 与程序员无关性仍不够理想 当需求变更经常仍是牵一发动全身

© 2010 PISX 7

项目管理的两个方面 软件开发模式

它是属于管理层的 是软件工程管理

• 归口：项目经理 软件架构管理

它是属于技术层的 是软件架构与编码管理

• 归口：软件架构师（注：架构师不只是管软件架构，同时还有系统架构）

先下个结论： 只有敏捷（或者某一天来一个更高级的开发模式）——仍然没用！因为还有很多问题解决不了！

© 2010 PISX 8

基于架构的开发模式 ABD——Architecture-Based Development

本概念最早产生于 1999年。 基于架构的开发模式

目标：• ABC——Architecture-Based Coding( 基于架构编码 )• AOP—— 面向切面编程（ JAVA 中的术语）• ABD 主要面向应用的基本架构

再下一个结论： 架构管理比软件开发模式还要重要！

• 原因：架构管理最终是在保证软件质量的前提下，保证工期！ 一个简单场景：

• 小团队，小项目，有架构管理，无敏捷，它有可能成功• 小团队，小项目，无架构管理，有敏捷，它仍不能成功

© 2010 PISX 9

并非新概念——架构的沿革 ABD 基于架构的开发模式

这一概念并非新概念。因为，我们一直在为架构奔走：• DOC/VIEW（文档 /视图结构）• UML/MDA （ Model-Driven Architecture ）• CORBA(通用对象请求体系架构， IDL）• WEB SERVICE（网络服务， WSDL）• MVC• MTS （ Multi-Tier System）• REST （ Representational State Transfer 表述状态转移）• SOA （ Service-Oriented Architecture ）

我们时刻忙于一个概念，但没有考虑我们应用的架构• 其它编程语言不需要• 但 PHP没有它不行！

© 2010 PISX 10

模式管理 VS 架构管理 模式管理

你何时完成

你做出来

实现功能，完成测试，无法保证与程序员无关性

架构管理 你何时怎样完成

你必须这样做出来

不仅只要求实现，同时限制了你怎样实现，因而保证了与程序员的无关性

© 2010 PISX 11

都是 PHP 惹的祸！！ 架构管理随团队产生！随应用的复杂而增强。

MFC—— 架构：一切都是类， DOC/VIEW分离。 VB6.0 ，由向导为你产生合理的软件架构。 VS.net——把架构用到的 WEB 应用之中 JAVA——SSH+(JSF 、 Tapestry) 的运用是良好架构的保证 ruby——Ruby On Rails 是良好架构的框架

很明显，架构管理， 首先要有好的开发框架。 PHP ？？

• zend?• symfony?• codeigniter?• yii?

© 2010 PISX 12

从现有其它语言看架构管理目标 第一：以往是：要有详细的与源程序一致的开发设计文档。

现在的要求是：程序就是文档。即程序的风格一致，具有“最高”的可读性！

第二：可维护性，可测试性高，开发周期短， 第三：具有高度的与程序员无关性 第四：最少限度的修改。最高限度的代码重用。

© 2010 PISX 13

现有的架构技术 其它编程语言发展，给我们留下了很多的架构技术

从 DOC/VIEW 到 MVC从三层架构到多层架构从数据库操作封装到 DMM ， ORM 新技术的流行： ActiveRecord,TableDataGetway从面向对象，到设计模式。

我们要问，这些技术有用吗？帮助我们解决了什么问题？

© 2010 PISX 14

关于 MVC

MVC—— 用一个标准实现完全面向对象，从而实现与程序员无关性把用户界面实体和其对应的代码分开。

• 用户界面实体：即是视图 VIEW对应界面实体的代码实体，使用事件映射，实现事件驱动模型。这个对应视图的代码即是模型 Modal• 你如果会 JAVA SSH ，或 VS.NET ，你会发现，你只能编写这样的模块

而实现事件映射的，则是控制器 Controller 。这就是人们所说的 MVC 。

© 2010 PISX 15

在 MVC 基础上的编程规范 在 MVC 基础上的编程规范——简易的规范能够更进一步实现

代码与程序员的无关性。

MVC所有模块均是面向对象模式的类。完全面向对象，则实现了第一层次的代码与程序员的无关性

在此基础上，只要规定：• 每个类都是单一职责的• 每个函数都是单一输入输出的

于是，则更加进一步保证了代码与程序员的无关性

注意： MVC 可以实现完全面向对象，非面向对象，也可以做到MVC ，这里不是把MVC 当成目标，而是把完全面向对象作为目标。同时，成熟的 MVC架构，应当是符合 IOC 模式的。

© 2010 PISX 16

关于 DMM 、 DDD

DMM——把纯数据操作与业务逻辑分隔成不同的输入输出单元，进一步简化代码，增强可读性，可维护性，可扩展性。

DMM 是指领域模型 (Domain Modal) 。 DDD 则是 Domain Driven Development ，领域驱动设计

MVC 实现了最早的三层结构：用户层，逻辑层，数据层。 但数据层仍包括业务逻辑与数据访问。于是人们想到了进一

步分开。即有了现在的多层结构。 纯数据访问很简单，在 PHP 中，你可以直接使用 ADODB 。 但现在人们为什么要用 propel或者 doctrine?

因为我们确实需要 DMM ， DDD

© 2010 PISX 17

DDD 提供了什么？ DDD 的目标，是处理系统业务逻辑。通常， DDD把业务逻辑封装为：

实体 值对象

规侧 服务

模块 聚合

工厂 资源库

本质上，将复杂的业务领域使用规范的，或遵循一种标准的编码方式来实现。其根本的目标，是可扩展，易变更，易维护。

© 2010 PISX 18

关于 ORM

ORM ，抽象数据操作类上面，再增加一层更具体的公用操作代码。

数据层实现 DMM 的方式，通常是通过 ORM 实现的。 ORM 是指 Object Relation Mapping ，即对数据库数据实现对象

关系映射。 作为 ORM ，这一技术最早流行是在 JAVA 中， Hibernat 是 JAVA

中用得最多的 ORM框架。通过 Struts, Spring, Hibernat 即我们常说的 JAVA 的 SSH 构成了 JAVA 面向大型应用的框架。

PHP 则是 propel 与 doctrine 最为有名。而 doctrine属后起之秀。

但随着 ROR冲击， ActiveRecord 与 TableDataGetway 架构被引入到了 PHP 中，但 PHP 仍是相对落后。

比如， RUBY 中，现在有更先进的 DrySql, 这在 PHP 中至今仍没有。

© 2010 PISX 19

为什么要 ORM ？ 数据库操作，需要有大量的 CRUD 。 只要有 CRUD ，就需要拼装 SQL 语句。 ORM 把 CRUD 变成通用模块，于是，业务逻辑与纯数据操作

就能分开。 通过这一方式，开发中就可以省去大量的编码。

任何开发框架的最基本的目的，就是让你开发时少写编码

© 2010 PISX 20

关于设计模式 设计模式让核心代码更加松耦合。同时增加易用性与可扩展

性。

例如，一些 PHP框架中提供了 APP ，或 APPLICATION类。实际上它常常是一个聚合模式的类（比如使用 FACADE 模式）。不仅方便使用，同时使得开发的代码规范、简单！

我们清楚：大型应用必不可少的有：Session ， Logger ， ErrorHandle ， it18n ， Validator ， Filter

一些框架中就是用相关模式，将其聚合到了 APP 之中。为用户开发提供了极大的方便。

© 2010 PISX 21

框架——要还是不要？ 不仅需要框架，而且要的是好框架。证据：

JAVA 有 SSH + （ JSF 、 Tapestry) vs.net 就是框架模式，（ VC 最早的 MFC 就是框架） RUBY 的成功，就是 ROR框架的成功

对于程序员： 你说了不算——编程规范太多，他不执行的！ 程序说了算——所有程序，他都是要调通的！

• 框架比编程规范还要有效！！ 结论：

架构管理，如果能借助一个好的框架，则相当方便。

但是： PHP框架选用，则是相当困难的一件事情

© 2010 PISX 22

PHP 架构管理中框架的使用 三种方式：

选用一个 PHP框架• 目前没有真正支持 VIEW 的框架• SMARTY 不是标准的 VIEW 。（ STRUTS也不是）

– FLEX > .net > tapestry > JSF > struts > smarty

• 标准的 VIEW 应当如同 VS.NET( 用过的人一定忘不了它的WEBFOM ， WEBTABLE）

DIY 一个适合自己的框架• 很多 PHP 开源的软件都这样做，如 SUGAR CRM 。• 因为， ZEND 不可选， sysmfony也不定完全适用于企业级开发。 PHP 还有什么？

• 但 DIY 的结果，仍没有我们想要的 VIEW 。自己写一个框架

• 这是被指责为最不明智的。• 但如果真的写了，那可是自己享用的最方便的方式。

© 2010 PISX 23

关于 VIEW

VIEW 应当是什么样子？ PHP 的悲剧： SMARTY 照抄 STRUTS ， Prado 照抄 Tapestry ， log4php

照抄 log4j…… ActionScript 的 Flex 的成功：照抄 vs.net

• 结论：开源的未必都是最领先的！• 有时，有大公司投入财力研发后得出的结论，要比开源开发者拍脑袋想出来或抄出来的更具有参考价值。

真正的 VIEW 是界面部件化，从而实现整个软件使用方式与界面风格的一致性。这是软件易用性的基本保证！

© 2010 PISX 24

为什么从 PHP 要转向 RUBY

JSP 要编译。并且是强类型的。 PHP 是非强类型无需编译就能运行的语言。 同时它是开源的。 语言本身的简易性是吸引用户的根本。

早期 JSP 开发人从 JAVA 走向了 PHP

但开发者需要的是面对大型应用。 ROR 为架构师的架构管理提供了方便。

PHP 现状： 面对大型应用，你只能有以下三种选择：

• 降低对框架的要求——选用，或 DIY ，或自己写• 等待合适的框架出现（不太现实）• 而今 PHP 开发人则转向 RUBY

© 2010 PISX 25

你是否会选择框架了？ PHP 的 MVC 中没有真正易于架构管理的 VIEW 。如果这一目

标放宽。我们可选的也是相当的少： symfony, prado, yii

如果是小型应用，有人使用 codeigniter + log4php + htmlpurifer 再加其它应用需要的第三方开源

，也是一个好办法。 codeigniter 最差的就是它的 logger 了。

官方框架： Zend Framework ，请谨慎选用！

敏捷开发模式——需要敏捷开发框架的支持！

© 2010 PISX 26

软件架构管理的具体目标 可靠性（ Reliable）。软件系统对于用户的商业经营和管理

来说极为重要，因此软件系统必须非常可靠。 安全性（ Secure）。软件系统所承担的交易的商业价值极

高，系统的安全性非常重要。 可升级（ Scalable）。软件必须能够在用户的使用率、用户

的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

可定制化（ Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。。

© 2010 PISX 27

软件架构管理的具体目标 可扩展性（ Extensible）。在新技术出现的时候，一个软件

系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。

可维护性（Maintainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。

客户体验（ Customer Experience）。软件系统必须易于使用。这与部件化 VIEW 是分不开的。

市场时机（ Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。只有好的框架才能提供最快速的开发！

© 2010 PISX 28

软件基本架构设计的一些原则 基本原则

分层—— MVC+DMM 多层结构（与框架有关）重用——代码类库（与框架有关）顺序——先界面，后数据库，最后编码（MVC才能做到）测试——日志管理（与框架有关），代码错误管理。版本管理。

团队原则 编码规范——限制程序员偏好 项目词典——集中管理各类命名 独立编码——要求按标准编码集中规范——以规范检查与验证

© 2010 PISX 29

好的架构应当是什么样子 用户界面（视图 view）部件化，实现界面风格与使用方式

的一致性。 除用户界面（视图 view）和入口文件之外，全部面向对象 程序员能够实现 AOP—— 面向切面编程 采用设计模式实现松耦合，可扩展。符合 SOLID 原则。 所有的类是单一职责的，所有的函数是单一功能的。并且尽

可能是单一输入输出处理模式的。 所有命名：类、函数、常量、变量有《项目词典》为参照的

标准进行规范。 安全：输入验证，防 XSS ，防 SQL注入。错误与日志管理。

一句话：实现与程序员无关性，同时实现架构管理目标。

© 2010 PISX 30

只有架构管理也能管好项目 不一定要敏捷。 PDCAR也行！

• plan计划， do it 立即实施， check it 实施中检验， action again吸取教训后再次行动 , record 继续备案供以后借鉴

项目管理的关键： 风险控制——设计阶段：对架构与技术风险的评估 质量控制——良好的架构管理，保证编码质量 进度控制——与程序员无关性的规范编码，工作量可知，进度可控。

结论：不是不要敏捷，而是说：架构管理不可少！敏捷开发模式——需要敏捷开发框架以及架构管理的支持！

© 2010 PISX 31

总结 ABD ， AOP

MVC——IOC• module

– calss– event map or

notation(action)

• view– componnent-based

• control DMM ， DDD

• Domain Driven Development– Domain modal 、 busness

modal» entity» value object

» factory

» specification mode» resource» service» aggregation» module

ORM• Active Record• Table Data Getway• DrySql

Libraries• database & other

澎湃进取，睿智从容！ Contact information:Hot Line: 400-620-9980Website: www.pisx.com