注意：如果您认为在建筑时至少吃掉了一半的狗，那么本文不适合您。
模型是某种形式的现实的抽象表示。
我们假设架构师已经完成了对未来系统的需求收集并进行了分析。
架构的开发只需要从处理信息（数据）的基本概念的概念和采用开始：传输，存储和处理。 此外，信息输入/输出的形式，处理方案，数组的抽象结构和数据元素本身也是信息（就像整个应用程序一样），并且遵循相同的基本概念。
基本概念导致了第一个想法，并创建了第一个数据处理模型。
由于嵌套概念的差异，可以不同地调用处理数据的模型。 名称之一是数据流，其中元素通常是将来实现特定数据操作任务的扩展模块。
体系结构的基础（主要模型）将是主要数据移动业务流程的模型（应用程序将用于什么目的）。 这个阶段非常危险：许多原始想法可能会淹没建筑师。 这种思想流必须被遏制。 抑制梦想的欲望或画出一堆不必要的方案。 现在，您只需要创建一种方案即可依次获取主数据，存储和处理。 没什么 这里不需要分解。 这种方案是基础，是体系结构的主要代表，应该始终在眼前。 作为业务流程可以是技术图。
第二个主要模型将是添加辅助业务流程和数据。 例如，添加了用户模型，访问控制（ACL），日志记录模型，监视模型，事件模型等。 基于第二个模型，已经有可能开发第一个数据库模式和/或数据仓库以及一个原型应用程序。 在此阶段，可能会了解是否要制作整体应用程序，组件，应用微服务方法或其他方法。 事实很有趣：在整体和每个微服务之间（在微服务架构中），从基本概念的观点来看，没有区别。 从这一刻起，有必要开始开发体系结构证明文件。 架构原理文档是有关架构决策和解释的原因的推理记录器。
基于第二个模型创建第一个应用程序原型可以显示该应用程序的直接好处。 原型肯定是形式化的应用程序布局。 例如，您可以使用条件按钮代替详细的表格，这些条件按钮基于随机数据生成器创建现成的元素。
创建第二个主要模型和第一个原型后，您可以开始分解，扩大，开发其他体系结构表示形式和模型。 但是第一个主要模型和第二个主要模型将是基本的。 在进一步发展的过程中，可以对第一和第二个模型进行改进，完善和完善。