技术架构角度

技术架构（architecture）视点或企业技术架构（ETA）定义了技术和产品使用的可重用标准和指南，并描述了它们如何互操作以及如何支持其他视点（业务和信息）。

企业技术体系结构不仅应定义部件级建议，还应定义这些技术组件的哪些组合或配置应在单独的实现（技术模式）中重复，以及哪些组合应作为共享基础结构（技术服务）实际重用。

启动企业技术架构开发工作

任何一个EA观点都应该从定义未来状态开始——在这里，需求被识别，EA原则被建立，未来状态模型被创建。然后定义当前状态体系结构，执行差距分析并创建迁移路线图。

在开始任何建模工作之前，请认识到所有模型都是从企业架构（EA）流程生成的。EA实践者和相关角色必须通过遵循流程来生成模型。

企业技术架构组织概念

技术领域：传统的技术架构方法将组件组织到基于技术或组织相似性的技术领域中。几个相关的组件可以这样分组；公共域包括网络和数据库。

图1

尽管技术领域模型是必要和有用的，但它们本身并不足够。技术规划需要一个整体的、端到端的视图。特别是，设计人员（架构师或工程师）必须清楚地表达模型，这些模型能够更有效地表达应用程序和共享服务交付的目标。这种类型的技术领域方法的一个典型结果是，对单个技术组件集进行了优化，但没有对这些组件的集体优化直接映射到应用程序需求。需要来自每个域的组件来定义完整的端到端应用程序

技术模式：模式有助于从业务需求到技术（基础设施）设计的映射。设计或蓝图代表了一些需要重复的东西——技术模式具体地包含了整个类或一组应用程序成功所需的所有组件。

技术服务：服务是作为单个单元（包括流程和人员）实现和重用的组件，但不必对任何一个应用程序都是必需的。它们通常由来自多个域的组件组成，但并不总是如此。通用技术服务包括广域网、大型机、分析集成（数据仓库）和事务集成（EAI、IEI）。技术服务也可以直接支持应用服务。其他合理的组件集合模型也存在，包括框架，比如Java EE；如果有用的话，将它们考虑进来。

下面是一个3/N层的事务模式-

标签：架构,模型,EA,技术,应用程序,EA874,组件
来源： https://blog.51cto.com/u_15127596/2748971