开发架构又称为代码架构，主要为开发人员提供切实可行的指导以实现软件产品。 开发架构依赖于企业的其他架构

• 业务架构：企业战略和需求产生的架构，表明如何达成企业盈利，以及满足客户需求。业务架构通常包含了业务概念和业务流程

• 应用架构：基于业务架构生成的系统的功能划分，功能流程

• 数据架构：基于业务架构，生成的数据架构，包含了概念模型，数据存储，数据流动流程

• 软件架构：基于应用架构和数据架构，生成的系统架构风格和质量要求。比如经典的MVC，微服务。以及高可用质量要求

• 部署架构：基于软件架构功能和质量要求，部署系统的架构。如网关，数据库，部署节点的物理部署等

• 开发架构：又称为代码架构，用于系统开发。满足如上的各个架构需求，比如

  • 如果数据架构除了传统数据库外，包含了大数据等NOSQL，开发架构如何支持这俩种数据库，开发架构是否需要·提供一个API支持访问俩种数据库，还是为了灵活性，各自适配！
  • 如软件架构如果采用消息服务，则开发架构需要引入消息服务组件，且开发架构提供配置，支持消息的服务质量
  • 如果部署架构中数据库采用了主从， 开发架构主要需要明确如考虑如何支持主从。

开发架构的产出通常是企业自有的代码框架。代码框架能让项目在实施阶段快速落地，能让不同的团队，比如企业各个外包方，企业内部各个技术团队等能同一套技术体系交流和参与开发，开发架构的架构如下:

开发架构的架构分为3层，第一层确定编程语言，第二层确定开发框架和规范，第三层包含了开发架构的各个功能模块。如下说明，并强调如过缺少模块，会导致的后果

开发架构的“模块”	描述	缺少后果
程序语言	确定编程语言，比如Java，Go，Python，Rust，PHP等。每个语言都在特定领域有用优势，比如Java适合大型企业应用，互联网应用，Go同Java类似，但在大型企业应用上还缺少生态。Rust适合高并发，低延迟的核心服务，但对业务系统开发还缺少生态支持。	选择开发语言通常根据项目的特点来决定，如果不指定开发语言，各个团队的技术栈无法通用。团队开发效率降低。
技术框架	开发框架用于整合开发架构中的各个模块， 选择开源的开放框架能快速实现开发架构，对于Java来说，选择SpringBoot/Spring Cloud, 国内的Solon，JFinal等， 如果企业打算自己研发开发框架，面临的问题是如何持久迭代开发框架。	缺少技术框架，难以整合 开发架构中的各个模块。 如果自研开发框架需要专门的团队维护
模块划分	项目包含的模块，如公共包，API包，工具类等模块，模块以 Maven POM形式体现出来。在微服务中，系统定义了系统的接口一般需要单独一个模块，需要发布到仓库供其他使用。
包结构划分	每个模块里，Java包名的划分。通常有俩种划分方式，按照应用架构划分，如com.xxx.custoerm,com.xxx.order. 或者软件架构划分,如常见MVC分层中的com.xxx.dao，com.xxx.web ,这里的xxx指的是公司或者项目缩写。
单元测试框架	单元测试开发框架，如使用mockito 模拟第三方服务，如使用TestContainer来启动测试数据库，Redis等基础服务，采用Cucumber来管理和执行单元测试。	如果缺少单元测试框架，项目不具备单元测试能力，项目交付将越来越慢，交付的产品故障越来越多。
性能测试框架	对于系统的关键业务，需要有性能测试，包括使用JMH测试单个服务，或者使用jmeter测试 服务接口。	缺少性能测试框架，则关键功能的迭代可能导致性能问题而无法在上线前被发现。
可观测性框架	如果项目缺少可观测性，无法持续演进和优化系统，无法让系统运行的更可靠。最基础的的可观测性就是log日志。其他可观测还包括整合链式跟踪，指标监控系统等等。	可观测性对架构的高可用，高性能非常重要。
多环境支持	支持开发，测试，生产环境。这通常通过不同配置文件实现，Spring框架允许在项目启动的时候传入环境参数，Maven打包软件也允许根据不同环境打包	缺少多环境支持，运维部署多环境会不可避免手工修改配置
配置文件管理	配置文件规范，多环境下的配置文件，多数据源的SQL文件等等。比如像mybatis这样的sql文件如何存放，gRpc协议文件如何存放
配置文件参数	开发架构使用的技术组件和框架都具有默认的配置参数，这些参数配置的通常较为保守，需要显示的在配置文件里体现出来比如数据库连接池，需要显示的配置连接数以及超时相关配置	技术组件和框架的用默认参数通常设置保守，如果不显示的制定配置参数，开发人员会忽略导致系统出现性能或者高可用问题。比如Dubbo的超时，有的系统设定为数秒是合理的，有的系统设定为数百毫秒是合理的
配置中心集成	配置中心，如Apollo，Nacos这样的服务可以存放多环境的配置参数。配置中心能在线修改配置并同步到部署的系统上
部署方案	包含了打包脚本，部署脚本，以及如何部署系统到各种环境。
第三方依赖管理	对第三方库做出明确的使用规范，如统一使用Log4j2，JSON序列化工具统一使用Jackson。	第三方依赖如果不妥善管理，可能引来安全问题，或者运行时候包冲突。比如第三方包的错误版本导致不存在的API。可能在系统上线后才发现导致系统故障。
分布式框架	在分布式架构中，选择一个分布式框架有综合的考虑。比如，仅内部系统，可以使用效率更高的，基于二进制的分布式框架，如dubbo，gRpc。参考本书分布式API以及性能序列化协议。对外则可以提供基于HTTP的REST或者SOA。
安全组件和规范	涉及系统不被非法调用，或者最终客户非经授权访问其他客户数据。比如Web应用中，通过JWT对用户访问授权比如多租户场景，通过对SQL重写，强制客户只能访问自己的数据对于开发架构中使用的第三方组件，也应该时刻关注其可能得安全漏洞。如Spring框架过去经常出现的Spel漏洞	对于大多数企业和互联网应用，安全是重中之重。开发架构应该明确规定如何确保系统安全。
开发规范	通过文档描述系统的开发规范，并使用或者IDE插件，或者第三方检测工具检测，如开发规范中，禁止使用SQL拼接以避免SQL漏洞，并使用Sonar这样的工具扫描检测。开发规范即包含Java这样的规范，也包含了各个组件使用规范，比如MyBatis规范，Dubbo规范。
API规范	微服务需要暴露API时候，需要制定API规范，如RESTFull规范，gRpc规范等等。这些规范规应该规定调用入参数和出参，以及异常情况。也会在高可用场景下，定义限流，降级等情况	TODO
Changelog和Readme.md	项目使用的简单说明和发布历史，可以放在其他文档里，考虑到在线文档疏于维护。最好在项目代码里有一份简要说明。Changelog包含了每次发布的更改以及详细说明的文档地址，Readme包含了项目的用途，功能使用说明，安装配置说明等等。