32 | 架构：系统的概要设计
许式伟
该思维导图由 AI 生成，仅供参考
你好，我是七牛云许式伟。
我们第二章 “桌面开发篇” 就快要结束了。今天我们把话题重新回到架构上。
基础架构与业务架构
桌面开发篇我们主要涉及的内容如下。
对于一位架构师而言，其架构工作的内容可以大体分为两块，一块是基础架构，一块是业务架构。
基础架构，简单来说就是做技术选型。选择要支持的操作系统、选择编程语言、选择技术框架、选择第三方库，这些都可以归结为基础架构方面的工作。
基础架构的能力，考验的是选择能力。背后靠的是技术前瞻性和判断力。这并不简单。大部分架构师往往更容易把关注点放到业务架构上，但实际上基础架构的影响面更广，选错产生的代价更高。
架构师之间的差距，更大的是体现在其对待基础架构的态度和能力构建上。真正牛的架构师，一定会无比重视团队的技术选型，无比重视基础平台的建设。阿里提倡的 “大中台、小前台”，本质上也是在提倡基础平台建设，以此不断降低业务开发的成本，提升企业的创新能力。
业务架构，简单来说就是业务系统的分解能力。基础架构其实也是对业务系统的分解，只不过分解出了与业务属性几乎无关的部分，形成领域无关的基础设施。而业务架构更多的是分解领域问题 。
一旦我们谈业务架构，就避不开领域问题的理解。所谓领域问题，谈的是这个领域的用户群面临的普遍需求。所以我们需要对用户的需求进行分析。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了架构设计在系统开发中的重要性，从基础架构与业务架构两个方面入手。强调了需求分析对业务架构的重要性，并提出了分解系统的方法论。在系统设计阶段，明确子系统的职责边界和接口协议是至关重要的。评判系统分解方式的优劣需要考虑功能的使用界面和实现的高内聚低耦合。此外，文章还探讨了MVC架构在桌面程序开发中的应用，并强调了实战经验对架构设计的重要性。通过实例分析，读者可以深入了解架构设计的重要性和相关的方法论，对系统设计有更清晰的认识。文章内容涵盖了接口自然体现业务需求和功能实现准则，强调了系统分解能力和高内聚低耦合的重要性。在概要设计阶段，以子系统为维度阐述系统各个角色之间的关系，强调了系统如何被有效地串联起来。概要设计阶段也应该有代码产出，以降低风险并给予每个子系统或模块的负责人更具象且确定性的认知。文章内容丰富，涵盖了系统设计的重要步骤和关键考虑因素，对于系统架构设计有着重要的指导意义。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《许式伟的架构课》，新⼈⾸单¥68
《许式伟的架构课》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(21)
- 最新
- 精选
- 饭老师，我想请教一个问题，我们公司系统都是传统的流程式的管理系统，各功能模块之间是通过某些业务字段状态，产生业务关联。比如一个最简单流程例子，完成模块A操作(状态=1)，才能做B操作(状态=2)，然后是模块C操作(状态=3)，有的状态判断可能是多种复杂条件。后果是功能间耦合性很高，导致没办法轻松往流程中添加或删除一个模块。一直在思考，有什么办法能解藕，但没想到办法，老师有什么建议没？针对这种流程式的业务管理系统（如仓储系统，物流系统），功能模块间的解藕
作者回复: 把流程上的具体的任务和流程剥离，有一个独立负责流程的控制方来控制流程，任务只关注自己的业务所需的输入输出。
2019-08-14725 
kevenxi最近在编写一个系统中某个子系统模块的概要设计，结合课程思考，现在要完成的其实不应是概要设计，应该是详细设计。一方面，概要设计要以子系统维度来阐述系统各角色之间的关系。这一部分，在该子系统设计中，还是需要的，但已不是关键设计内容。重点已是该子系统内部各功能模块的分解实现，包括数据结构，即数据表设计；还包括界面和流程，甚至关键按钮的伪代码（算法）。 详细设计，很多公司都交给程序员了，文档都是后补的。但是先有详细设计，再让程序员去实现，应该说效率要高一些。作者回复: 详细设计也是非常关键的，不能先实现再设计
2021-04-033
3岁大宝宝老师，想问下您对普元EOS的构件开发有什么看法么作者回复: 没有体验过
2019-09-051
胡鹏原文: 如果存在大量说不清业务意图的函数，或者存在大量职责不清的模块和类，就知道他基本上还处在搬砖阶段。 针对细化到每一行代码的设计和作用，很久之前我就意识到了自己这方面没做好，，很多自己写的代码自己无法知道是否优良，于是各处搜索资料，买课程等，， 可能是因为水平不够，看到了答案还不知道答案或者是目前所搜索到的知识面不够，还没找到，，， 不过本课程，让我眼前一亮， 到底哪些会变，哪些不太会变，哪些需要如何抽象，用什么样的设计模式更好，这些东西已经看到说明的苗头了，不知老师后面会有这一块更详细说明嘛， 如果没有，还望老师能在这个方面，提点一下理解学习路径呢作者回复: 不需要细化到每一行代码，判断好不好第一重要的是使用界面（接口）。这方面后面第四章架构篇还会接着讨论。
2019-08-191- Geek007再读此篇，真是受益匪浅。把自己平时的工作也都梳理了一下。谢谢许老师，希望有机会加入七牛云。
作者回复: 欢迎🤝
2020-01-09 
顺哥聊成长Model代表核心业务逻辑吗？我之前以为Controller是，Model只是数据结构及其操作的包装，就像操作系统内核的机制和策略分离一样，Model是机制，Controller是策略。作者回复: 大原则是做胖Model层
2019-08-22
yl最近在思考如何重构遗留的一个项目，正好可以用许老师讲的方法论指导实践。 请教一个问题，c语言开发的项目在数据库中间件的选择上有什么建议？ 我们的项目因用户采购数据库不同，可能要调用不同厂家的数据库，目前通过odbc方式调用，维护代价高，没有找到比较成熟的c语言中间件(类似java的orm框架)作者回复: 限定c语言的原因是什么
2019-08-13
不温暖啊不纯良之前写过一个数据清洗的功能，如果让我现在再去写，我会先确定这个业务中的稳定点和变化点是什么？ 稳定点就是。读取数据，处理数据，输出数据，操流程监控。 变化点就是。读取的数据源不一样，读取方式不一样，处理数据的规则不一样。输出数据的源不一样，方式不一样。 我可以把当做一个io子系统，子系统中读，处理，记录，写有四大模块。再分别设计出4个最基础的业务模型。 比如读数据，分别是从文件读取。从关系数据库读取。从非关系数据库读取。 比如处理数据，分别是处理前的水平，规则的集合，处理后的数据。 比如写数据，分别是写入文件，写入关系型数据库，写入非关系型数据库。 比如记录。我可以把它设计成一个切面，分别获取读取数量，正在处理的数量，和正在写入的数量。 我把这些基础业务模型设计成抽象类或者是接口，如果上层业务需要丰富接口，需要实现和集成这些基础模型。2021-04-198
孙光专栏需要反复看反复练，这一篇收获很多。2019-11-154
泡泡龙许老师的深度真不是一两天能达到的，这看第三次了，每次都有新的知识理解。2020-03-043
收起评论
