许式伟的架构课
许式伟
七牛云CEO
立即订阅
20090 人已学习
课程目录
已更新 72 讲 / 共 77 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (9讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
许式伟的架构课
登录|注册

32 | 架构:系统的概要设计

许式伟 2019-08-13
你好,我是七牛云许式伟。
我们第二章 “桌面开发篇” 就快要结束了。今天我们把话题重新回到架构上。

基础架构与业务架构

桌面开发篇我们主要涉及的内容如下。
对于一位架构师而言,其架构工作的内容可以大体分为两块,一块是基础架构,一块是业务架构。
基础架构,简单来说就是做技术选型。选择要支持的操作系统、选择编程语言、选择技术框架、选择第三方库,这些都可以归结为基础架构方面的工作。
基础架构的能力,考验的是选择能力。背后靠的是技术前瞻性和判断力。这并不简单。大部分架构师往往更容易把关注点放到业务架构上,但实际上基础架构的影响面更广,选错产生的代价更高。
架构师之间的差距,更大的是体现在其对待基础架构的态度和能力构建上。真正牛的架构师,一定会无比重视团队的技术选型,无比重视基础平台的建设。阿里提倡的 “大中台、小前台”,本质上也是在提倡基础平台建设,以此不断降低业务开发的成本,提升企业的创新能力。
业务架构,简单来说就是业务系统的分解能力。基础架构其实也是对业务系统的分解,只不过分解出了与业务属性几乎无关的部分,形成领域无关的基础设施。而业务架构更多的是分解领域问题 。
一旦我们谈业务架构,就避不开领域问题的理解。所谓领域问题,谈的是这个领域的用户群面临的普遍需求。所以我们需要对用户的需求进行分析。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 老师,我想请教一个问题,我们公司系统都是传统的流程式的管理系统,各功能模块之间是通过某些业务字段状态,产生业务关联。比如一个最简单流程例子,完成模块A操作(状态=1),才能做B操作(状态=2),然后是模块C操作(状态=3),有的状态判断可能是多种复杂条件。后果是功能间耦合性很高,导致没办法轻松往流程中添加或删除一个模块。一直在思考,有什么办法能解藕,但没想到办法,老师有什么建议没?针对这种流程式的业务管理系统(如仓储系统,物流系统),功能模块间的解藕

    作者回复: 把流程上的具体的任务和流程剥离,有一个独立负责流程的控制方来控制流程,任务只关注自己的业务所需的输入输出。

    2019-08-14
    10
  • leslie
    程序离开了实践那就变成了理论:其实数学本来也就是一门实战性学科;证明理论的对错不是用嘴巴说出来的,而是通过大量的方式方法去验证论证:“实践是检验真理的唯一标准”。
    2019-08-13
    2
  • 胡鹏
    原文: 如果存在大量说不清业务意图的函数,或者存在大量职责不清的模块和类,就知道他基本上还处在搬砖阶段。
       针对细化到每一行代码的设计和作用,很久之前我就意识到了自己这方面没做好,,很多自己写的代码自己无法知道是否优良,于是各处搜索资料,买课程等,,

     可能是因为水平不够,看到了答案还不知道答案或者是目前所搜索到的知识面不够,还没找到,,,
    不过本课程,让我眼前一亮, 到底哪些会变,哪些不太会变,哪些需要如何抽象,用什么样的设计模式更好,这些东西已经看到说明的苗头了,不知老师后面会有这一块更详细说明嘛,

    如果没有,还望老师能在这个方面,提点一下理解学习路径呢

    作者回复: 不需要细化到每一行代码,判断好不好第一重要的是使用界面(接口)。这方面后面第四章架构篇还会接着讨论。

    2019-08-19
    1
  • Lrwin
    关于抽象的理解:
    抽象的东西一定是稳定的,比如我说:"一个女孩很漂亮",漂亮这个词很抽象,每个人都会有对漂亮这个词的定义,所以这句话很稳定,大家很难差生歧义。那这句话如果我换成"这个大眼睛的女孩很漂亮",这个描述是我对于一个具体的描述(大眼睛),这样的描述会产生歧义(有的人觉得小眼睛的女孩才漂亮)因为这样的描述太具体了。
    回到架构思维,必须考虑两点:1. 需求分析(不错需求分析,就不要开始做软件) 2.系统分解(也可以称为各层级的抽象)

    关于系统分解:
    我们仅仅需要根据需求 ,抽象的划分出不同的子系统,比如电商系统可以划分为: 会员系统、商品系统、订单系统、库存系统等。。这些系统划分期初不一定肯定准确,但是根据需求粗略的划分就好.
    再将我们需求中的用例(场景)拆解成不同的小功能点,比如下单流程: 1.验证库存 2.验证会员资质 3.计算价格 4.生成订单。。 根据场景拆分后的静态动作划分到不同的子系统就可以了。
    划分后的静态动作在子系统中进一步拆解,拆解为包、类 等。 拆分的过程一定遵循:从抽象慢慢过渡到具体的一个过程
    2019-11-29
  • 孙光
    专栏需要反复看反复练,这一篇收获很多。
    2019-11-15
  • 3岁大宝宝
    老师,想问下您对普元EOS的构件开发有什么看法么

    作者回复: 没有体验过

    2019-09-05
  • 公号-技术人成长
    Model代表核心业务逻辑吗?我之前以为Controller是,Model只是数据结构及其操作的包装,就像操作系统内核的机制和策略分离一样,Model是机制,Controller是策略。

    作者回复: 大原则是做胖Model层

    2019-08-22
  • Dimple
    代码即文档。代码是理解一致性更强的文档。

    还有老师描述的如何判断一个程序员是不是搬砖的,实在是太形象了,自己也曾经经历过那种时刻。现在不敢说完全没有,所以按照老师的这个准则,好好对比对比,对于自身成长来说,很是重要。
    2019-08-15
  • Aaron Cheung
    打卡32 一个继承很多的python项目 感觉不太好重构……
    2019-08-15
  • yl
    最近在思考如何重构遗留的一个项目,正好可以用许老师讲的方法论指导实践。

    请教一个问题,c语言开发的项目在数据库中间件的选择上有什么建议?
    我们的项目因用户采购数据库不同,可能要调用不同厂家的数据库,目前通过odbc方式调用,维护代价高,没有找到比较成熟的c语言中间件(类似java的orm框架)

    作者回复: 限定c语言的原因是什么

    2019-08-13
  • 梦醒十分
    许老师辛苦啦!
    2019-08-13
收起评论
11
返回
顶部