4、 对象设计
在架构规范的指导下，设计从技术上扩展和修改了分析结果。虽然分析阶段的领域对象建模应该与技术细节无关，但是对象设计完全依靠于技术因素，包括平台、语言的类型和架构开发阶段选择的供给商。分析时，抬头望着星星，但在设计阶段，则要脚踏实地。理论上，为了维持业务对象的基本属性和行为，除非绝对必要，不应该破坏它们。
在架构结果的指导下，具体设计工作应该说明所有类的规格，包括必须实现的属性、它们的具体接口和伪代码或操作的纯文本描述。规格说明应该足够具体使得和模型图结合时，它可以提供所有必须的编码信息。在许多自动化软件生产过程中，我们可以从面向对象图生成代码框架。图5和6 说明了对一些领域对象的高层和具体设计对象。注重桩（stub）和框架（skeleton）在图中经常是不可见的，因为它们对设计人员和编程员来说是透明的。我将它们包括在图6中以说明EJB的基础部分。
图6 对象设计模型：订单EJB具体设计
在完成了具体对象设计后，还需要完成领域对象的对象-关系映射。原因是虽然面向对象方法学现在非常流行，但是大多数流行且成熟的持续性存储却是关系型的。另外，在许多情况下，客户的IT基础设施已经反映了对商业RDBMS供给商的投资和偏爱。所以，将领域对象转换成关系模型或数据库表是非常重要的。虽然有许多容器治理的持续性工具，但它们不能取代好的关系数据库设计。
5、 实现
在良好的架构和具体设计条件下，实现应该是一个明确的任务。另外，因为我们设计和实现架构原型阶段的纵向联合部分，所以实现阶段应该更没有什么值得惊奇的。在许多组织中，开发者经常过早地到达实现阶段。尤其当治理者盯着开发人员确保在编码，而不是做他们认为在浪费公司时间的其他事情时，这种情况变得更加严重。
结果，不再花数小时或数天绘出UML草图，而是通常在发费数周或数月编码的同时测试自己的想法。由于在这种情况下，所有地架构决定和设计都是在编码阶段做出来的，所以经常过了数月后才发现开发的方向出错了。
6、 验证
验证包括测试验证系统按设计要求运行并满足需求。验证过程发生在整个开发生命周期的开发和产品环境中。单元测试、集成测试和用户测试本身就是非常重要的主题。
7、 装配和部署
构件装配和解决方案部署在J2EE开发中非凡重要。开发和产品环境可能非常不同。假如EJB在系统中，你需要使用供给商特定的工具得到容器自动生成的类，因为，正如我以前指出的，Web和应用程序构件配置对不同的供给商来说是不同的。你也必须考虑要部署的系统是否含有供给商特定代码实现。在可扩展架构中，系统结构应该是稳定的但也应该在不影响整个系统的条件下支持新或老构件的增量部署。
8、 运行和维护
在最后阶段，应用程序到了用户手中，你必须给他们提供培训和文档。用户会发现错误并可能要求新特性。你必须适当地改变治理过程来处理这些情况。你不必为了部署一个新构件或取代老构件而关闭一个正在运行的系统。
架构开发过程
知道了必须做出许多架构决定，因此我们必须为架构开发描绘一个过程。对于一个企业来说通常有许多应用项目，它们中的一些可能跨越数年，结果是系统演化包含许多周期。在你的领域里存在着许多跨越多个项目的通用需求。你应该不费力地在它的生命周期或其他项目中使用以前项目周期的可扩展且可重用的架构。为一系列软件应用提供同属结构和行为的通用框架和可重用软件架构是非常需要的。
假如是第一个J2EE项目，架构必须做原型、测试、度量、分析并在迭代中进行推敲。蓝图提供了许多好的设计指导和实践，宠物店示例程序可以作为一个很好的参考架构。最有效地快速、高质量发布好的解决方案的方法是接受和扩展蓝图参考架构并插入你自己的业务构件。你最后要做的就是改造车轮。
接受一个参考架构
就我的理解，宠物店架构的精华是模型-视图-控制和命令模式。你可以将这些模式应用到以Web为中心和以EJB为中心的系统中。对于每个领域对象，视图用嵌套的jsp表示。控制器处理相关的业务事件，领域对象封装业务逻辑、事物和安全。我们使用门户servlet作为中心控制器接受和截获所有用户的动作。它将业务事件分发给特定的调用领域对象改变持续状态的领域对象控制器。依靠事件处理结果，控制器选择下一个要展现的视图。下面是我们可以修改并在大多数J2EE应用程序中使用的主要构件：
a、 MainServlet：门户构件，Web容器和框架之间的接口
b、 ModelUpdateListener：获得模型更新事件对象的接口
c、 ModelUpdateNotifier：当更新模型事件发生时通知侦听器
d、 RequestPRocessor：处理所有从MainServlet来的请求。
e、 RequestHandler：即插即用请求处理构件接口
f、 RequestHandlerMapping：包含请求处理映射规则
g、 RequestToEventTranslator：中心请求处理器根据请求处理映射规则代理即插即用请求处理构件的请求。将http请求转换为业务事件
h、 EstoreEvent：业务事件
i、 ShoppingClientControllerWebImpl：代理EJB层门户控制器
j、 ScreenflowManager：控制屏幕流，选择视图
k、 ModelUpdateManager：EJB层模型更新治理器，通知什么模型由于事件发生了改变
l、 ShoppingClientControllerEJB：EJB层门户，为EJB客户提供远程服务
m、 StateMachine：中心事件处理器，根据状态处理映射规则代理即插即用处理构件的事件处理
n、 StateHandler：EJB层状态处理接口
o、 StateHandlerMapping：包含状态处理映射规则
扩展参考架构
虽然蓝图示例程序是一个好的起点，但应该根据每个项目或领域修改它。设计模式是可重用的微体系结构，可以使用它扩展参考架构。提供了一组有用的J2EE模式目录的蓝图和23个"四人帮"模式都是非常不错的资源。例如，假如想扩展参考架构支持工作流治理，你可以在部署或运行时动态地在中心控制器注册事件处理器。中心控制器会询问每个注册的事件处理器直到一个处理器返回消息表明到了命令链的末端。
插入你的业务构件
J2EE技术对每个人都是一样的，但是不同的领域，我们要解决的问题是不同的。一旦建立了一个基本的J2EE框架，必须实现一些用例来说明架构确实可以为你的领域服务。可以通过选用捕捉系统要害功能的场景来实现，这些场景经常使用来展现要害的技术风险。从领域分析模型入手，可以象我们在图5和6中那样将领域对象映射成高层和低层设计模型。实现低层设计模型并测试是否真正在工作。假如每件事都按计划运行，那么重新评估风险开始下一个迭代，扩展要考虑的场景并选择更多的场景扩展架构的覆盖范围。经过几次迭代后，原始的架构原型应该变得稳定。识别要购买的构件，要保留的遗留系统和怎样将它们对接。下一步是软件设计，你可以使用设计指导中规定好的类似方法和过程继续开发。
一步一步
我们使用一个过程来将一个复杂问题分解为较小的几个问题，这使得我们可以更轻易的理解和解决它们。在本文中，我们将J2EE开发分解为八个步骤，主要集中在架构和设计。我已经阐述了重要的架构并为架构决定提供了一个过程。我也讨论了J2EE架构师的角色和可交付产品。
学习使用这些步骤开发J2EE解决方案就象学习跳舞的步骤一样。首先需要自觉并持之以恒地练习基本步骤。但是，一旦你对它们相当熟悉后，应该将它们放在一起并将注重力更多地集中在规模、速度、流和特定上下文中每一步的节奏。但永远不要让一个过程限制了创造性。而应该接受和扩展过程以满足自己非凡需要。记住，最终目的是提供满足客户需求的完整的J2EE解决方案。
