根据系统使用人、客户等收集而来的业务实现的背景要求组成的原始需求文档分析，包括了功能要求、质量（性能要求）、约束（时间、预算、可行性分析、风险评估、是否需要对接三方）。这里要输出一份整理过后的需求文档，包含了要做什么（功能范围、非功能性需求），能不能做，能做到的前提要求和要面临的问题，怎么做（进入系统分析实现阶段）。
确定关键需求不仅要对功能需求（如用例）进行筛选，还要对非功能需求进行权衡，最终确定对架构起关键作用的需求。如需求是以高性能并发度为关键还是以可扩展性为要求或同时满足，因为考虑到成本、上线时间和现有系统的影响会舍弃一部分需求，需要确定关键需求：核心功能、高风险功能。
概念架构设计1个决定4个选型：决定如何划分顶级子系统；架构风格选型（C/S还是B/S架构）；开发技术选型（java）；集成技术选型（API）；二次开发技术选型（API）。
细化架构设计5视图法：分别从逻辑架构、物理架构、数据架构、开发架构、运行架构进行设计，每一块的关注点不一样，可细化粗粒度。
领域建模领域建模的精髓是 业务决定功能，功能决定模型。将需求业务转化为抽象的模型对象之间的流转关系。
常用的表达方式是类图 表达模型之间的关系，听得最多的是“建模”。模型的建立也是逐步完善的，还包含了状态（流程图）、特性要求等文字说明。
关于如何领域建模 有专门的 领域驱动设计 方面的书可以参考。
架构验证可快速开发一个统一框架（一个原型、一个技术难点）来贯彻架构的设计，再对原型进行测试评审 再对架构进行补充。
最后可以总结为可以用5视图法从各方面来描述系统的架构，然后用6步骤来描述怎么实现架构。不过现在还流行一种就是将业务逻辑与物理架构放一起 忽略其中的实现细节。
软件架构就是实用而且优雅的设计，它不在于分多少层，或者应用了多少种设计模式/架构模式等。它应该是以满足实现用户需求为前提，以开发人员普遍可接受为根本的，而且要符合系统特性和业务发展需要的，从软件设计的角度，能够达到层次清晰、可维护、可重用、可扩展…就非常优秀了，无需刻意去纠结分了多少层，是否使用了什么模式，有多么抽象等。以面向对象设计为例，基本目标是“高内聚、低耦合”，为此我们可能会遵循一些常见的设计原则（例如经典的SOLID设计原则）。
通常我们所说的模式，其实又分为很多种，并不是仅仅指的是“设计模式”（设计模式也有千千万，并不是只有常见的GOF 23种设计模式）。通常包括：企业架构模式、设计模式、SOA模式、企业集成模式等等。
强调一下，架构要讲求“实用”，而且开发人员普遍可接受，要符合现状的。否则，再“优雅”的设计，都会沦为高成本的“花架子”，生搬硬套和过度设计只会让项目“流产”。