
蒂拉克·米特拉
本书的核心理念体现在恰到好处(just enough)这个词上。架构固然应该对实现起指导作用,但这个指导作用应该留有一定的余地,使我们可以对架构进行反思,并根据项目的发展情况对其做出调整。软件架构要想做得务实,就需要把握住恰到好处的原则,架构师要知道应该把模块细化到何种程度,才能使开发团队在既定的大方向下灵活地进行发挥。
2020034。 读起来蛮累的一本书,之前看网络小说,16个小时我能看200万字,这本书18万字,我看了近18个小时,做了165条笔记…… 架构师应该是我的努力方向,这么多年项目做下来,系统技术架构图、技术路线图、数据流转图、实施方案等做了很多,新的技术也学了很多,但感觉自己还完全是野路子,需要一套理论把这些东西串起来,融合在一起,或者说给我的选择以支撑,我觉得这就是我看这本书的最大期待吧。从这个角度讲,这本书很是符合我的需要,也正因如此,作为大量知识点和体验的串联工具,这本书让我又查看了很多相关文章和资料,所以耗时才这么长吧~ 看书过程中最有意思的就是发现好多东西似曾相识,有时候会发现书中某一章节可以把自己的很多知识点串起来从而体系化,而最棒的事是一段文字把自己一直搞不清的一个点突然戳破,那种淋漓尽致之感,有时真想大喊大叫一番~ 同时,对于互联网时代读书的方便性我体验的越来越深了,想当初读研时看书,看到一个新的知识点或者名词等,只能用笔记下来,有机会去网吧时上网查,耗时耗力,很多东西嫌麻烦就不会去查了;现在只需长按,选择查询,即可尽读百家讲解,快乐无边啊~ PS:一边带娃一边看这本书,真是煎熬啊,太难专注思考了,效率极低。
二零一九年读完的第九十一本书,在IBM工作的印度小哥写的书,把架构这快赢骨头写的简单易懂确实不容易,真心值得推荐。断断续续用了大半个月才读完,只要是在中间关于基础设施的那部分被卡住了,中途去补了一下这方面的知识,对于一个基于云计算做惯了应用层面东西的人来说,基础设施层其实是挺陌生的。但是如果要做ToB服务的话,这一块也是我们必须要懂的,稍后还需要补充相关的知识。
以TOGAF方式来划分架构领域: The Open Group Architecture Framework(TOGAF,The Open Group n.d.)发现:对于任何一种软件系统来说,其架构的范围以及架构所要处理的问题都是相当广泛的。因此,它从下面这4个领域分别对架构做了定义: 业务架构(Business Architecture)—对业务策略、组织、职能、业务流程及信息需求的结构及交互所做的描述。 应用架构(Application Architecture)—对应用程序的结构及交互所做的描述。该架构把这些应用程序视为一组可以提供关键业务职能并且可以对资产进行管理的能力。 数据/信息架构(Data/Information Architecture)—根据其主要类型和来源,对企业中的数据、逻辑数据资产、实体数据资产以及数据管理资源的结构及交互所做的描述。 技术架构(Technical Architecture)—对平台服务、逻辑技术组件与实体技术组件的结构及交互所做的描述。
建议想快速阅读的朋友可直接从第十一章开始阅读,整本书的核心内容都在这一章节里面。 另外,这本书其中有些内容需要读者有一些相关的知识积累,这样理解会更加深刻。事实上,软件架构的细节还有不少内容,但对这本书中所描述的而言,已经足够了解整体的情况了,其实这也正是软件架构的一个目的,让各方业务人员从一个比较高的角度去了解软件的结构。这样做能够让各方人员有一个相对集中的目的,这对后期的软件施工实现十分重要。
还不错的一本书,跟bob大叔的整洁架构之道不是一个路子,主要是从实施细节出发进行了论述,很多观点都是从实践中得到的干货,但是论述的比较散,感觉作者想把自己知道的方方面面都说出来,但是深度一般,从另外一面也能看出来作者经验非常的丰富,给出的建议都值得重视。以后工作中可以经常翻翻。
很实用,讲了架构方法论,完全可以当做一本工具书来用。常打开看看,次次有新知。
重点看了前7章,对个人的帮助还是挺大的,后面有时间再看
书讲的不错,就是翻译不太给力,看着费劲[裂开]
写尽IT系统的精华。 相比纯粹技术,更加侧重从工程实务角度思考问题。