写点什么
创作场景
- 记录自己日常工作的实践、心得
- 发表对生活和职场的感悟
- 针对感兴趣的事件发表随笔或者杂谈
- 从 0 到 1 详细介绍你掌握的一门语言、一个技术,或者一个兴趣、爱好
- 或者,就直接把你的个人博客、公众号直接搬到这里
登录/注册
收录了 项目技术架构图 频道下的 50 篇内容
架构图对于系统的设计和文档化来说都是很重要的。它们必须是自描述的,并且与代码保持一致性。为了保证利益相关者能够看懂架构图,需要遵循一些原则。

本文是架构设计实践五部曲系列文章的第五篇,技术架构的战略和战术原则。本篇讲述如何保证在做技术架构时,实现一个稳定、出色的系统。

本文是架构设计实践五部曲系列文章的第一篇,架构与架构图。本文将对架构作深入的阐释,并教你什么时候画架构图、怎么画架构图。

企业级转型,或者搞中台,都不是“一锤子买卖”。

业务架构设计需要考虑哪些因素?业务架构设计的难点和挑战是什么?

本次分享介绍图数据库的设计和实践经验。

本文介绍爱奇艺云剪辑Web端。
P&P(设计模式与最佳实践,patterns & practices)自2002年推出第一个.NET项目分层架构图至今已经6年多,面对服务化、移动及智能化、富浏览器客户端、P2P应用的需求,原有架构需要结合.NET最新的技术进一步细化,这样才能为架构师和开发人员提供更好的指导作用,近期微软P&P团队启动了应用架构指南V2.0项目。

多数架构师都是停留在“技术架构,或软件架构的层面。少有人能做到“开放性思维”,从商业问题的本身出发, 带领团队让“理真的越辩越明”。
开发和架构的界限难以捉摸。有些人认为这并不存在,架构只是开发者所做的设计过程的扩展而已;另外一些人说这是一个鸿沟,它只能由那些做到高度抽象,而且不会陷入实现细节的开发者才能跨越。这之间有个平衡,但是你怎么从开发者成为架构师呢?

别怕AI抢饭碗,它正逼着我们进化。

2020 年 3 月 16 日,得物技术团队在三个月的时间内完成了整个交易体系的重构,交付了交易平台化项目——五彩石项目。整个项目重新设计了 6 个核心交易应用,完成 180 项操作,21 个系统重新发布,相应的优化迭代还涵盖了社区、交易、供应链的解耦,交易平台化的演进、底层交互协议的更新、全链路压测落地等等。为了了解五彩石项目的整个构建过程,InfoQ 采访了得物 App CTO 陈思淼、交易平台和稳定性平台负责人金思宇。

从业务到模型只是一个复杂的“预备过程”,开发才是大家关注的重头戏。

踽踽独行上下求索总是痛苦,如果有良师益友陪伴点拨必能事半功倍。从新手码农到高级架构师,要经过几步?要多努力,才能成为为人倚重的技术专家?本文将为你带来一张程序员发展路径图,但你需要知道的是,天下没有普适的道理,具体问题还需具体分析,实践才能出真知。

项目涉及十余家本土伙伴,跨语言、跨团队协作链条较长~

将模型化的业务架构转化为需求方案,及其落地的关键。
随着敏捷和精益实践的流行,企业架构师的角色也在悄然地发生变化,最近ThoughtWorks的技术专家Kevin Hickey在MartinFowler的博客上发表了一篇文章,介绍了自己对新时代企业架构师的理解,本文便是由该文翻译整理而来。

如果项目是对错综复杂的旧遗留系统进行现代化改造或是将所有工作负载迁移到云上,该怎么办呢?

互联网行业历来有“胜者通吃”的传统,阿里如今在业务和技术上的成功也使得“中台”这个词名声大噪,好像一颗“银弹”就此诞生了。但是,熟悉架构设计的朋友也都很清楚,软件工程上是没有“银弹”的,而阿里的优秀也不是学学“中台”就可以移植的。
面向服务架构的决策建模(SOAD)框架可以帮助捕获那些经常重现的架构决策,并在相关项目中使用这些决策来指导设计。在这篇IEEE文章中,Olaf Zimmermann探讨了这种以决策为中心来指导设计工作的方法。另外他还描述了在SOAD元模型中使用的两类模型:指导模型和决策模型。