收录了 项目技术架构图 频道下的 50 篇内容
本文是架构设计实践五部曲系列文章的第五篇,技术架构的战略和战术原则。本篇讲述如何保证在做技术架构时,实现一个稳定、出色的系统。
架构图对于系统的设计和文档化来说都是很重要的。它们必须是自描述的,并且与代码保持一致性。为了保证利益相关者能够看懂架构图,需要遵循一些原则。
本文是架构设计实践五部曲系列文章的第一篇,架构与架构图。本文将对架构作深入的阐释,并教你什么时候画架构图、怎么画架构图。
适当数量的软件架构图可以极大地改善开发团队和外部利益相关者之间的沟通。我们需要对目标受众有很好的了解,以及对内容的深思熟虑。不要因为有很多不好架构图就认为架构图是不必要的或者没有用的。
企业级转型,或者搞中台,都不是“一锤子买卖”。
多数架构师都是停留在“技术架构,或软件架构的层面。少有人能做到“开放性思维”,从商业问题的本身出发, 带领团队让“理真的越辩越明”。
业务架构设计需要考虑哪些因素?业务架构设计的难点和挑战是什么?
本文是架构设计实践五部曲系列文章的第四篇,单体式与分布式的应用架构,本篇讨论应用架构在产品架构的基础需要考虑的事情。
ADMIT详细表述了任何 IT架构工作中都应考虑的决策点。虽然ADMIT格式与其他企业架构框架类似,但ADMIT更关注影响最终结果的特性和驱动力,这使得它可以与其他形式化的企业架构设计和评价方法学结合使用。
“我们特别强调数字化转型下的企业架构升级,要做到整体与细节的统一性,做到从高阶到细节的一致性,同时去满足细节需求,最终能汇总成一个完整的整体架构。 ”
开发和架构的界限难以捉摸。有些人认为这并不存在,架构只是开发者所做的设计过程的扩展而已;另外一些人说这是一个鸿沟,它只能由那些做到高度抽象,而且不会陷入实现细节的开发者才能跨越。这之间有个平衡,但是你怎么从开发者成为架构师呢?
架构师的职责已经远超设计和业务问题的范畴。设计方案能否实现是衡量他们最终成功与否的唯一标准;因此他们应该亲身参与到项目之中并提供必要的帮助。
在本文中,作者Eltjo R. Poort提出了一种开展架构工作的方法,名为风险与成本驱动架构,它能够帮助架构师在敏捷世界中变得更为高效。使用风险与成本能够帮助决定关注点的架构重要性。
如果项目是对错综复杂的旧遗留系统进行现代化改造或是将所有工作负载迁移到云上,该怎么办呢?
本次分享介绍图数据库的设计和实践经验。
本文介绍宜信微服务架构的实践经验。
百度的核心业务对基础架构有没有特殊的要求?中台和微服务在架构领域处于什么样的位置?云原生架构的本质和影响是什么?中小企业架构师该如何设计IT架构?带着这些问题,InfoQ记者采访了QCon 北京 2020《架构演进》专题出品人,百度基础架构部主任架构师郑然。以下为采访实录。
今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构,之前的工作过的公司eBay、携程、唯品会都是平台型互联网公司,所以今天主要带着平台架构视角和大家分享心得体会。
面向服务架构的决策建模(SOAD)框架可以帮助捕获那些经常重现的架构决策,并在相关项目中使用这些决策来指导设计。在这篇IEEE文章中,Olaf Zimmermann探讨了这种以决策为中心来指导设计工作的方法。另外他还描述了在SOAD元模型中使用的两类模型:指导模型和决策模型。
将模型化的业务架构转化为需求方案,及其落地的关键。