收录了 项目技术架构描述 频道下的 50 篇内容
本文转载自技术琐话公众号
本文是架构设计实践五部曲系列文章的第一篇,架构与架构图。本文将对架构作深入的阐释,并教你什么时候画架构图、怎么画架构图。
本文是架构设计实践五部曲系列文章的第五篇,技术架构的战略和战术原则。本篇讲述如何保证在做技术架构时,实现一个稳定、出色的系统。
架构图对于系统的设计和文档化来说都是很重要的。它们必须是自描述的,并且与代码保持一致性。为了保证利益相关者能够看懂架构图,需要遵循一些原则。
软件架构文档是企业应用开发过程中的重要一环,理解一个项目中的架构文档的关键是理解它在项目生命周期中所扮演的角色。在这个虚拟研讨会中,InfoQ希望能从顶级的软件架构专家们那里找到软件架构文档的重要性,特别是在敏捷软件开发环境中如何记录架构。
踽踽独行上下求索总是痛苦,如果有良师益友陪伴点拨必能事半功倍。从新手码农到高级架构师,要经过几步?要多努力,才能成为为人倚重的技术专家?本文将为你带来一张程序员发展路径图,但你需要知道的是,天下没有普适的道理,具体问题还需具体分析,实践才能出真知。
通常,架构要么是Word文档中虚无缥缈的描述,要么完全是由技术来驱动的。这两种方式都很糟糕,但什么才是好的表达呢?Markus Völter为我们介绍了如何围绕你的架构将其发展为一门语言。这样一门正式的语言,虽然只是架构的副产物,但它最终会成为激发系统未来重大发展的良好基础。
多数架构师都是停留在“技术架构,或软件架构的层面。少有人能做到“开放性思维”,从商业问题的本身出发, 带领团队让“理真的越辩越明”。
本文定义了业务架构的主题和规则。与其他方式不同,只有业务职能和业务信息才能成为架构中的实体,共同形成业务架构的主题。另一方面,业务架构的规则是对业务架构主要及次要任务的描述。
ADMIT详细表述了任何 IT架构工作中都应考虑的决策点。虽然ADMIT格式与其他企业架构框架类似,但ADMIT更关注影响最终结果的特性和驱动力,这使得它可以与其他形式化的企业架构设计和评价方法学结合使用。
架构师的职责已经远超设计和业务问题的范畴。设计方案能否实现是衡量他们最终成功与否的唯一标准;因此他们应该亲身参与到项目之中并提供必要的帮助。
架构师的职责是什么?对一个公司的核心价值是什么?核心能力又是什么?如何培养这些核心能力?
面向服务架构的决策建模(SOAD)框架可以帮助捕获那些经常重现的架构决策,并在相关项目中使用这些决策来指导设计。在这篇IEEE文章中,Olaf Zimmermann探讨了这种以决策为中心来指导设计工作的方法。另外他还描述了在SOAD元模型中使用的两类模型:指导模型和决策模型。
适当数量的软件架构图可以极大地改善开发团队和外部利益相关者之间的沟通。我们需要对目标受众有很好的了解,以及对内容的深思熟虑。不要因为有很多不好架构图就认为架构图是不必要的或者没有用的。
本文由阿里巴巴技术专家九摩分享架构师工作经验。
从业务到模型只是一个复杂的“预备过程”,开发才是大家关注的重头戏。
在本文中,作者Eltjo R. Poort提出了一种开展架构工作的方法,名为风险与成本驱动架构,它能够帮助架构师在敏捷世界中变得更为高效。使用风险与成本能够帮助决定关注点的架构重要性。
“我们特别强调数字化转型下的企业架构升级,要做到整体与细节的统一性,做到从高阶到细节的一致性,同时去满足细节需求,最终能汇总成一个完整的整体架构。 ”
解决特定的问题,本篇文章重点讨论应对系统架构的方法。如今,系统架构在业内还没有定型的固定方法,一般会讲:需求分析、系统分析与设计、UML、领域建模、设计模式、软件工程等,笔者不打算这样讲,这样下来会有厚厚一本书,希望从简洁、可落地实践的角度去阐述系统架构,后面的文章再给出每种架构具体可实践操作的方法。
Boyan Mihaylov回顾了自己在传统瀑布式软件架构和敏捷软件架构下的工作经历。他描述了两者在以下三个方面表现出来的相似性及差异性:软件架构扮演的具体角色、软件架构的时间跨度以及软件架构的输出。