架构设计感想

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

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

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

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

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

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

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

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

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

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

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

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值