架构设计感想

在软件设计中架构域是如何划分的，架构域包括：业务架构、数据架构、产品架构、应用架构、技术架构。 

在一篇文章中看到关于架构的划分， 同时应该是岗位或者人的职责划分。

系统架构师，从系统的维度，负责整体系统的架构设计，主要是基础服务和各系统间协调上，着眼全局不太注重某个应用本身架构，比如关注服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用等方面的基础架构设计。

业务架构在很多企业其实是Boss在做决策时已经定下，后续跟进人员包括业务规划、业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。这中间包含2个重要因素需要考虑：时间和成本。

数据架构很容易想到DBA，数据架构需要解决3个问题：1.系统中需要什么数据（基础）；2.数据怎么存储；3.数据架构设计（与业务实体进行关联对应）。这3个问题涉及三个部门工作：产品需求调研，DBA提供部署数据方案，开发人员设计表结构。

产品架构自然而然是产品经理需要负责的工作，这个架构离使用者最近，从业务要求、用户使用习惯、人群喜好等设定产品的功能或者交互流程。

应用架构是通过对产品架构的分析，我们需要哪些应用系统，最后怎么把这些应用系统集成在一起。假设一个产品需要微信端、APP端、Web端等各端来呈现，除了这些前端应用还需要后台系统来管理，如后台管理平台、客户管理系统等。

技术架构主要针对开发或架构师，根据应用架构来梳理技术需求，再做技术选型，最后把技术和技术之间的关键点描述清楚。

技术架构解决的问题包括：如何进行纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。由于应用架构体系是分层的，那么对应的技术架构体系自然也是分层的。大的分层有微服务架构分层模型，小的分层则是单个应用的技术分层框架。大的技术体系考虑清楚后，剩下的问题就是根据实际业务场景来选择具体的技术点。各个技术点的分析、方案选择，最终形成关键技术清单，关键技术清单考虑应用架构本身的分层逻辑，最终形成一个完成的技术架构图。

 从上面架构分类来看，前面一个架构是后面架构的输入，技术架构是最终产品的实现过程。

在小公司可能没有这么多所谓架构，老板一句话就开始干活，越快干完越好，说不定老板赏一个“大保健”。但是在大公司不可能这样，因为在大公司，人多沟通不方便，必须靠制度来约束。

按照套路来设计架构必不可少，统一的可视化架构图，对应的人只需要关注自己职责范围内的即可。

同时这些也为后来的人提供一个榜样，也是一种学习的资源。