收录了 软件实现技术架构图 频道下的 50 篇内容
本文是架构设计实践五部曲系列文章的第五篇,技术架构的战略和战术原则。本篇讲述如何保证在做技术架构时,实现一个稳定、出色的系统。
本文是架构设计实践五部曲系列文章的第一篇,架构与架构图。本文将对架构作深入的阐释,并教你什么时候画架构图、怎么画架构图。
架构图对于系统的设计和文档化来说都是很重要的。它们必须是自描述的,并且与代码保持一致性。为了保证利益相关者能够看懂架构图,需要遵循一些原则。
适当数量的软件架构图可以极大地改善开发团队和外部利益相关者之间的沟通。我们需要对目标受众有很好的了解,以及对内容的深思熟虑。不要因为有很多不好架构图就认为架构图是不必要的或者没有用的。
作者是一名从业数十年的软件架构师,在与不同领域、不同学科的软件工程师交流时,大家都会问,如何成为一名架构师,架构师需要掌握需要能力?作者将通过本文向读者介绍,什么是软件架构,什么是软件架构师,软件架构师要掌握什么样的技能以及如何获得这些技能。
Roy Fielding博士是IETF发布的HTTP和URI协议的主要设计者。HTTP和URI是两个最为重要的Web基础技术架构协议,因此Fielding博士可谓是Web架构的奠基者之一。这篇论文很不容易读懂,作为论文中文版的译者,笔者试图在这篇导读中为读者梳理出一个阅读的脉络。不过笔者还是希望读者能克服困难,亲自去读一下这篇论文,因为这篇论文实在是太精彩了。
开发和架构的界限难以捉摸。有些人认为这并不存在,架构只是开发者所做的设计过程的扩展而已;另外一些人说这是一个鸿沟,它只能由那些做到高度抽象,而且不会陷入实现细节的开发者才能跨越。这之间有个平衡,但是你怎么从开发者成为架构师呢?
Boyan Mihaylov回顾了自己在传统瀑布式软件架构和敏捷软件架构下的工作经历。他描述了两者在以下三个方面表现出来的相似性及差异性:软件架构扮演的具体角色、软件架构的时间跨度以及软件架构的输出。
业务架构设计需要考虑哪些因素?业务架构设计的难点和挑战是什么?
“我们特别强调数字化转型下的企业架构升级,要做到整体与细节的统一性,做到从高阶到细节的一致性,同时去满足细节需求,最终能汇总成一个完整的整体架构。 ”
本文围绕作者所精挑细选的“新技术顾问必读的十本书”出发,分享在培养“通用型软件技术顾问”的过程中的一些思考。
本篇整体介绍一下“DDD分段式协作设计”的步骤和内容。
多数架构师都是停留在“技术架构,或软件架构的层面。少有人能做到“开放性思维”,从商业问题的本身出发, 带领团队让“理真的越辩越明”。
本文介绍宜信微服务架构的实践经验。
本文定义了业务架构的主题和规则。与其他方式不同,只有业务职能和业务信息才能成为架构中的实体,共同形成业务架构的主题。另一方面,业务架构的规则是对业务架构主要及次要任务的描述。
软件开发团队一直反对“前期大设计”,而倾向于自组织团队中出现的架构设计,这可能导致低估软件架构重要性的心态。
架构师的职责已经远超设计和业务问题的范畴。设计方案能否实现是衡量他们最终成功与否的唯一标准;因此他们应该亲身参与到项目之中并提供必要的帮助。
本文介绍阿里资深技术专家六铢的架构方法论。
ADMIT详细表述了任何 IT架构工作中都应考虑的决策点。虽然ADMIT格式与其他企业架构框架类似,但ADMIT更关注影响最终结果的特性和驱动力,这使得它可以与其他形式化的企业架构设计和评价方法学结合使用。
了解软件架构基础比以往任何时候都要来得重要,因为我们现在构建的系统越来越趋于分布式化,而且开发团队也越来越分布式化。为了解开这些迷思,开发者需要了解五个与软件架构有关的事实。