架构之路 - 穿行在产品和业务之间(吴立峰)


Thinking on the Road 架构之路——穿行在产品和业务之间 吴立峰 wulifeng@liba.com #qcon 2011 hangzhou# 我的经验来自于一些各不相同的实践  各种软件项目(1996-2002)图形仿真、医院、公路、房地产、外贸、CRM  安家网(2000)进入互联网领域  ICE(2002)支持异地协同的 CAD 系统原型,有创意的实验室产品  MOSES(2003)按揭服务管理系统,成功运用了一堆新的方法  安家搜索(2004)借助原始的地图服务实现耳目一新的房源搜索  保险电子商务(2005-2006)领略什么是复杂领域  WE-NET(2006-2007)形式化的工作流模型及引擎,博士论文  篱笆建材 B2C(2008-2010)一次艰辛的转型,目前仍在继续 本文试图谈论我对三个问题的认知 产品 业务 技术 产品 什么是产品  为什么网站有产品?(我进篱笆的第一个困惑) 网站 频道 页面 产品? ? 产品 软件产品 互联网产品 移动产品 用户需要的是服务 计算机让服务数字化并且可管理 网络让服务极大丰富 网络让用户可以分享 移动让服务无处不在 Software as a Service  软件从未像今天这样可以深度融入生活  软件为个人用户提供了越来越多的功能和服务  网站只是入口,一个聚合软件产品的容器 直接为用户提供有价值的服务 产品是一种范式(Paradigm) 产品是一种态度 精益求精的作品 业务 软件教科书当中最常见的例子 Order Product 业务的本质 生产 实物产品 虚拟产品 信息产品 服务 流通 客户 企业 供应商 采购 销售 信息流 资金流 物流 管理 利润 = 收入 – 成本 生产 软件无法改变业务的本质 流通 软件无法改变业务的本质 管理 软件无法改变业务的本质 自动化的生产(80后) 软件可以改变业务的形式 精细化的管理(90后) 软件可以改变业务的形式 扁平化的流通(00后) 软件可以改变业务的形式 企业之间竞争的根本在于差异化 业务系统是千差万别的 管理是艺术,因人而异 业务系统是千差万别的 业务系统依然需要通过项目来度身定制 软件开发技术 十八个印象 1999 3-Tier Windows DNA 2000 Software Requirements 2002 Martin Fowler, UML Distilled UML 2002 Alistair Cockburn Use Case 2002 GoF Design Patterns 2002 Rational Unified Process 2002 Grady Booch The Complexity 2002 Alan Cooper, The Inmates are Running the Asylum Interaction Design 2003 Martin Fowler Analysis Patterns 2004 Grady Booch Architecture is Design 2004 Agile Manifesto 2004 Robert C. Martin, Agile Software Development SOLID Principles 2004 Eric Evans Domain-Driven Design 2006 Rod Johnson Spring Framework 2007, eBay Architecture Strategies Partition & Asynchronous 2008 Ivar Jacobson, Be Smart Simple but No Simpler 2009 SCRUM 2010 Daniel Teng, Building Your Silver Bullet Coding Dojo Connect The Dots The Dots 1999 ~ 2001 2002 ~ 2004 2005 ~ 2010 Analysis Patterns Design Patterns DDD Agile Coding Dojo SCRUM RUP UML Architecture is the Significant Design Complexity 3 Tier Requirements Spring Use Cases Simple but No Simpler SOLID eBay Interaction Design CMM XP MDA TDD Enterprise Architecture No SQL Web Services REST DSL PEAA RoR Lean Cloud Mobile .NET J2EE Node.js SOA Kanban Security CBD OO Oracle Visual C++ No Silver Bullet DevOps BPM EAI SQL Server My Dots 1999 ~ 2001 2002 ~ 2004 2005 ~ 2010 9 Analysis Patterns 5 Design Patterns 13 DDD 11 Agile 18 Coding Dojo 17 SCRUM 6 RUP 3 UML 10 Architecture is the Significant Design 7 Complexity 1 3 Tier 14 Spring 4 Use Cases 16 Simple but No Simpler 12 SOLID 15 eBay 8 Interaction Design OO SQL Server Oracle Visual C++ No Silver Bullet CMM XP MDA TDD Enterprise Architecture Web Services .NET J2EE SOA BPM CBD PEAA Spring DSL RoR Lean Cloud Mobile Kanban No SQL REST Node.js DevOps Security EAI 2 Requirements Connect My Dots 1999 ~ 2001 2002 ~ 2004 2005 ~ 2010 9 Analysis Patterns 5 Design Patterns 13 DDD 11 Agile 18 Coding Dojo 17 SCRUM 6 RUP 3 UML 10 Architecture is the Significant Design 7 Complexity 1 3 Tier 14 Spring 4 Use Cases 16 Simple but No Simpler 12 SOLID 15 eBay 8 Interaction Design 2 Requirements Connect My Dots 1999 ~ 2001 2002 ~ 2004 2005 ~ 2010 9 Analysis Patterns 5 Design Patterns 13 DDD 11 Agile 18 Coding Dojo 17 SCRUM 6 RUP 3 UML 10 Architecture is the Significant Design 7 Complexity 1 3 Tier 14 Spring 4 Use Cases 16 Simple but No Simpler 12 SOLID 15 eBay Design & Implementation Domain Understanding Practices Philosophy 8 Interaction Design 2 Requirements 应对变化的复杂度 变化  产品不断贴近用户的生活,精益求精  普通用户总是希望服务越简单越好(User Experience)  太复杂的服务不适合用“Self-Service”的方式完成  普通用户的数量非常庞大(Large Scale) 技术复杂度成为首要问题了吗?  规模带来的压力——NFRC – Non-Functional Requirements & Constraints – Performance, Stability, Scalability, Availability, Usability, Reliability – Compatibility, Testability, Reusability, … …  看产品的发展阶段  看产品的技术属性(比如:搜索、视频) 领域复杂度已是次要问题了吗?  现阶段互联网产品的领域复杂度比企业应用要简单许多, 长期而言并不确定  产品自身会趋于复杂(虽然总是说要保持简单)  互联网企业自身有盈利要求,终究会找到与产品能够完美 融合的商业模式,一旦涉及商业模式,复杂度就不请自来  传统企业在互联网的探索上一定会有所突破,它们的业务 复杂度会按照互联网的思维重新组织,但绝不会消失 复杂性图谱 High High 技术复杂度 领 域 复 杂 度 淘宝 支付宝 Application Science 百度 微博 QQ 地图 豆瓣 开心 人人 优酷 百姓 点评 安居客 天涯 京东 携程 当当 中小型电子商务平台 初创的社区 团购 LBS 盛大 巨人 魔兽 锤子和钉子  架构师是令人称羡的Title  架构工作被赋予了许多模糊的内容  我们通常对架构给予了更多的关注,而忽略了架构所需要 承载的领域,以及架构所存在的环境(Over Design) 应当把技术架构和领域模型分开考虑 领域 复杂度 技术 复杂度 功能 需求 非功能 需求 领域模型 技术架构 Analysis & Design 领域模型 Conceptual / Logical Structure Analysis Understanding / Modeling 技术架构 Implemental/Physical Structure Design 关注 Core Domain 才能化繁为简  Core Domain is Stable – Essence(本质) – Most Important User Requirements – Most Valuable Functionalities  Simple but No Simpler 实现 Core Domain 贯穿全程的自然映射 Problem Domain Architecture Decision Model Domain Model Code Domain Objects System Domain Services Agile Development (DDD + Clean Code + SOA) x Agile Beautiful Architecture Domain Modeling Clean Code 给所有程序员  技术 != 架构  企业 != 上市  技术 = (DDD + Clean Code + SOA) x Agile  仸何环境都足以让你脚踏实地地自我修炼 Thinking on Your Road 吴立峰 wulifeng@liba.com #qcon 2011 hangzhou#
还剩66页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

fengpy2009

贡献于2011-10-28

下载需要 15 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf