收录了 系统技术架构文档 频道下的 50 篇内容
本文是架构设计实践五部曲系列文章的第五篇,技术架构的战略和战术原则。本篇讲述如何保证在做技术架构时,实现一个稳定、出色的系统。
软件架构文档是企业应用开发过程中的重要一环,理解一个项目中的架构文档的关键是理解它在项目生命周期中所扮演的角色。在这个虚拟研讨会中,InfoQ希望能从顶级的软件架构专家们那里找到软件架构文档的重要性,特别是在敏捷软件开发环境中如何记录架构。
本文是架构设计实践五部曲系列文章的第一篇,架构与架构图。本文将对架构作深入的阐释,并教你什么时候画架构图、怎么画架构图。
解决特定的问题,本篇文章重点讨论应对系统架构的方法。如今,系统架构在业内还没有定型的固定方法,一般会讲:需求分析、系统分析与设计、UML、领域建模、设计模式、软件工程等,笔者不打算这样讲,这样下来会有厚厚一本书,希望从简洁、可落地实践的角度去阐述系统架构,后面的文章再给出每种架构具体可实践操作的方法。
适当数量的软件架构图可以极大地改善开发团队和外部利益相关者之间的沟通。我们需要对目标受众有很好的了解,以及对内容的深思熟虑。不要因为有很多不好架构图就认为架构图是不必要的或者没有用的。
承载每天数以万计的交易已经是主流电商网站的常态。
踽踽独行上下求索总是痛苦,如果有良师益友陪伴点拨必能事半功倍。从新手码农到高级架构师,要经过几步?要多努力,才能成为为人倚重的技术专家?本文将为你带来一张程序员发展路径图,但你需要知道的是,天下没有普适的道理,具体问题还需具体分析,实践才能出真知。
多数架构师都是停留在“技术架构,或软件架构的层面。少有人能做到“开放性思维”,从商业问题的本身出发, 带领团队让“理真的越辩越明”。
接到需求后,依据产品设计给出实现的阶段。
今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构,之前的工作过的公司eBay、携程、唯品会都是平台型互联网公司,所以今天主要带着平台架构视角和大家分享心得体会。
架构图对于系统的设计和文档化来说都是很重要的。它们必须是自描述的,并且与代码保持一致性。为了保证利益相关者能够看懂架构图,需要遵循一些原则。
架构决策涉及系统使用的基本概念,因为选择对代码的影响散布在整个软件中,而不是局部的。
日前互联网上出现了几个有关软件架构的新资源。Simon Brown和Kevin Seal发表了一组编写软件架构文档的指导。Mike Kavis也整理了一个指导架构师的框架,此框架可用于应对新架构带来的变化。
本文介绍了如何针对遗留系统进行技术栈迁移。文中给出了一些最佳实践,迁移步骤和案例分析。
通常,架构要么是Word文档中虚无缥缈的描述,要么完全是由技术来驱动的。这两种方式都很糟糕,但什么才是好的表达呢?Markus Völter为我们介绍了如何围绕你的架构将其发展为一门语言。这样一门正式的语言,虽然只是架构的副产物,但它最终会成为激发系统未来重大发展的良好基础。
当我们有了几百个上千个应用后,不仅仅需要单个项目的架构设计,还需要企业总体架构做顶层思考和指导。企业总体架构需要在 技术、业务、管理 之间游刃有余地切换,它包括业务架构、应用架构、数据架构和技术架构。
架构师是一个神秘而又神圣的名词,作为软件开发领域的设计师,架构师承载着太多的责任和挑战。对于一个程序员或者工程师来说,架构师就像是一个目标,一条道路,抑或是一座山峰。如何能够成为一名合格的架构师?架构师应该具备何种素质?而架构师又是如何做到持续不断的成长和提高的呢?带着这些问题,我们请到了五位InfoQ中文站的编辑,同时也是各领域出色的架构师或者咨询师,来谈谈他们心中的“架构师修炼之道”。
Boyan Mihaylov回顾了自己在传统瀑布式软件架构和敏捷软件架构下的工作经历。他描述了两者在以下三个方面表现出来的相似性及差异性:软件架构扮演的具体角色、软件架构的时间跨度以及软件架构的输出。
Digital Enterprise Agile Modelling —— DEAM
本文通过分析微服务架构与单体架构的性能特点与适用性,并对运营商系统进行梳理研究,提出了微服务架构系统适用性评估体系,同时对云原生时代运营商微服务改造策略进行研究。