在上一节有了业务架构的基础之上，当我们需要落地具体的技术方案时，此时就需要技术人员开始考虑技术架构了。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选项，把各个关键技术和技术之间的关系描述清楚。
基础结构解决的主要问题包括：如何进行技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。由于应用架构体系是分层的，那么对应的技术架构体系自然也是分层的。大的分层有微服务架构分层模型，小的则是单个应用的技术分层框架。大的技术体系考虑清楚后，剩下问题就是根据实际业务考虑选择具体的技术点。各个技术点的分析、方案选择，最终形成关键技术清单，关键技术清单应考虑架构本身的分层逻辑，最终形成一个完整的技术架构图。
简而言之，技术架构试讲产品需求转变为技术实现的过程。
单体应用架构
单体应用架构一般是比较传统的分为4层：数据层（Data Layer）、应用逻辑层（Business Layer）、表现层（Presentation Layer）和基础通用层（Common Layer）。
展现层
展现层是整个应用面向用户的入口，用户通过展现层实现与系统的交互。展现层为用户提供系统功能的操作、系统数据的展现。展现层按照面向的用户类型提供不同的交互服务。例如在业务场景中，用户有实操层用户、管理层用户、决策层用户。针对不同层级的用户，系统所提供的功能是不相同：
面向实操层用户，提供的是对系统的操作功能，满足业务日常运营。往往更多的是执行具体操作。
面向管理层用户，满足管理者的日常管理需求，通常提供经营数据、日常管理数据、团队业务数据等等。通过数据分析，改善日常运营的流程。
面向决策层用户，这一层的用户不需要太细的数据，为其提供企业的经营诊断数据和报告，辅助决策支持。
业务层
业务层是应用为解决业务需求，按照产品架构中的功能模块进行细化。业务层是对将产品层从粗到细的分解过程。这个过程是对业务的细化过程，把项目要交付的模块细分到最基本的单元。最基本单元是实现日常业务操作的最细粒度的功能点。由此，我们能够得到实现业务逻辑的全功能结构。
数据层
数据层按照应用的数据模型分别进行存储。这里的存储介质包含关系型数据库、NoSQL、分布式文件系统。
基础层
通用基础层是为系统提供通用能力的中间件，比如流程引擎、消息中间件、缓存、搜索引擎等等。这些中间件和业务是无相关性的，提供的是通用的基础技术能力。
基于上述分析，我们可以得到一个如下单体应用的技术架构：
分布式应用架构
分布式应用架构图实质是产品内部所有应用在分布式环境下的调用关系图。各应用间通过服务的形式相互调用，这是典型的 SOA 架构。在应用架构图中，SOA 架构中的服务注册、服务治理、服务发现这些 RPC 框架的基础平台功能不用在应用架构中体现。
应用架构图的重点是体现应用之间的逻辑关系和通信关系，体现产品的内部关系和外部关系。内部关系是产品内各应用的调用关系；外部关系展现的是产品与外部系统间的调用关系。将应用的内外关系呈现在应用架构中，产品在整个业务中的定位和影响将变得清晰。
应用间调用关系
在产品内部的各子系统之间，为了解决业务需求，通过应用之间的服务调用或者异步消息调用产生数据关系。通过产品架构图中得到的应用系统划分，按照系统间的调用关系，形成内部应用的集成架构图。在应用集成架构图中，需要标注调用链路中的业务含义，清楚的标注应用之间发生的业务关系。
外部系统调用关系
数据输入做为产品的业务数据来源，很大部分是外部系统提供。在应用架构图中，按照业务属性、来源关系进行对外部系统进行归类，并将外部的来源系统纳入整个应用架构中。我们知道计算机系统中，数据输入和数据输出是作为一个整体。应用架构中除了输入系统，输出系统做为整个产品的一部分，需要纳入到应用架构图中。
明确应用调用边界
应用边界对于产品的定位、产品的设计有很重要的影响。在应用架构中需要通过不同颜色的标注，来确定产品与外部系统的边界。通过不同颜色标注外部来源系统、内部应用、应用依赖系统、输出系统。为后续的规划、发展提供基础。
