内容简介
优秀的软件架构师应该既掌握业务知识又具备技术能力，做到这一点绝非易事，本书想要探讨的就是这个主题。这是一本真正的开源图书，我们邀请到50多位杰出的软件架构师参与写作。大家无偿地分享了各自的工作经验和心得，内容从规避风险的方法到组建团队的技巧，涵盖了架构设计的方方面面。衷心希望这97篇文章能激发您的思考，解决您工作中的困惑。
编辑推荐
O’reilly第一本开源图书，业界专家集体智慧创作。旨在“为全世界的软件架构师提供洞察力和指导”。集思广益、覆盖面广、写法新颖。技术社区及程序员博客热议。
目录
前言
客户需求重于个人简�?
简化根本复杂性，消除偶发复杂�?
关键问题可能不是出在技术上
以沟通为中心，坚持简明清晰的表达方式和开明的领导风格
架构决定性能
分析客户需求背后的意义
起立发言
故障终究会发�?
我们常常忽略了自己在谈判
量化需�?
一行代码比五百行架构说明更有价�?
不存在放之四海皆准的解决方案
提前关注性能问题
架构设计要平衡兼顾多方需�?
草率提交任务是不负责任的行为
不要在一棵树上吊�?
业务目标至上
先确保解决方案简单可用，再考虑通用性和复用�?
架构师应该亲力亲�?
持续集成
避免进度调整失误
取舍的艺�?
打造数据库堡垒
重视不确定�?
不要轻易放过不起眼的问题
让大家学会复�?
架构里没有大写的“I�?
使用“一千英尺高”的视图
先尝试后决策
掌握业务领域知识
程序设计是一种设�?
让开发人员自己做�?
时间改变一�?
设立软件架构专业为时尚早
控制项目规模
架构师不是演员，是管�?
软件架构的道德责�?
摩天大厦不可伸缩
混合开发的时代已经来临
性能至上
留意架构图里的空白区�?
学习软件专业的行�?
具体情境决定一�?
侏儒、精灵、巫师和国王
向建筑师学习
避免重复
欢迎来到现实世界
仔细观察，别试图控制一�?
架构师好比两面神
架构师当聚焦于边界和接口
助力开发团�?
记录决策理由
挑战假设尤其是你自己�?
分享知识和经�?
模式�?
不要滥用架构隐喻
关注应用程序的支持和维护
有舍才有�?
先考虑原则、公理和类比再考虑个人意见和口�?
从“可行走骨架”开始开发应�?
数据是核�?
确保简单问题有简单的�?
架构师首先是开发人�?
根据投资回报率（ROI）进行决�?
..
北京市公安局丰台分局备案编号：1101080539 
