星期二, 03月 3rd, 2009
开发者对平台-产品平台-产品线架构的探讨
平台是当前互联网的热点，大家都在想着建平台，特别是开放平台，这个Facebook，逼得大家都往这个概念上飞奔。对于我们技术人员来说，就得考虑怎么建这玩意。
探讨1：建平台，那么啥是平台？以前看到一篇文章《用平台的思想观察互联网》写的非常好。平台是一个供多方参与者获取价值诉求的环境。从这个定义中，可以分析到平台的几大要素：参与者，价值链，环境。
- 参与者：只有一个参与者，肯定没戏，原始社会不就这样吗？因而参与者必须是多个，所扮演的角色各相同，但基本上有这几类，利益输入者（换取另外一种价值），利益获得者（提供价值，换取利益），环境搭建者（维护、运营环境），游戏规则制定者（如何均衡的分配利益，满足利益获得者；如何客观的评估价值，满足利益输入者）。
- 价值链：“天下熙熙皆为利来，天下攘攘皆为利往。夫千乘之王，万家之侯，百室之君，尚犹患贫，而况匹夫“。这是平台存在的根本，也是商业性所要求的，是驱动参与者进入平台的“原力”，共产主义形式的平台目前还没看到。需要几条价值链？一般以某一核心价值链为中心，想多条也可以。
- 环境：参与者玩游戏、交换价值的地方。也是技术人员最关心的东西。
探讨2：产品平台与平台是啥关系？产品平台是平台的环境部分。在互联网领域，它首先提供容纳的能力，标识参与者的能力，支持利益获得者运行服务，支持利益输入者体验服务，支持游戏规则制定者有一只强力的手来调控价值链。对于技术人员来说，要搭建平台不是简单的一个技术平台，先得请我们的业务人员把平台的第一，第二要素搞清楚，否则失败的概念会挺高。
探讨3：开放平台与产品平台是啥关系？对于不同的平台，其开放的意义是不同的，但有一点是相同的：容许价值链的某一个点（或多个点）让第三方群体参与。例如，移动通过审批机制，允许SP参与到短信平台；Amazon开放商品供应点，允许第三方参与；淘宝开放平台的API，允许第三方提供网店的功能扩展。开放API只是开放的一种表现形式，而不是开放的本质，Amazon和移动就是很好的例证，开放的本质是价值链的开放，特别是利益获得者价值的开放，无利，开放了也没有价值。
探讨4：产品线与产品平台是啥关系？产品平台是平台的环境部分，与公司的价值链相对应；产品线是业务的实体部分，与公司的业务域相对应。一个或多个产品线可以运行在产品平台上；产品平台也可能是一个产品线。
探讨5：产品线是啥？围绕某一核心价值展开的系列产品，产品线中的产品承担的角色依据策略而各不相同，有的是核心价值的附加，有的是核心价值的放大器等等。比较典型的有:Google搜索产品线，支付宝的支付产品线。
探讨5：产品线架构与产品线是啥关系？产品线架构与平台、产品平台不具有直接关系。产品线架构是针对产品线的，为产品线里的产品提供共同的支撑，例如，共同的业务架构、共同的技术架构。产品线架构首先提供可重用的基础业务，支持产品的多样性、系列化、或形成“价值附加族”（以某一产品的核心价值为中心，研发的依赖核心价值而存在的其它产品，具有增强、放大核心价值的能力）；从技术上提供相同的基础环境、规范、工具等，简化产品的研发和缩短周期。
探讨6:如何构建产品线架构？以《架构的支撑框架和运营》一文为指导，实践之。
星期六, 02月 28th, 2009
架构的支撑框架与运营
更多内容在：
架构专栏
在《对架构的另类定义》一文中对架构进行了定义，虽然利用了事物本质来阐述，依然比较抽象，理解起来比较困难，因而再定义一个支撑框架。这种做法与事务研究方法是对应的：“架构定义”是概念，“支撑框架”是本体，“运营中的架构”是运动体。下图展示了这个理念：
【图示说明：】
- 第一个领域是需求域，包括R1，R2，R3。R1代表当前实际的需求；R2代表了目标，例如，企业战略指标，系统容量指标等；R3代表了当前架构，如果还没有系统，那么R3为空。R1，R2来自于受益人，此处的受益人可以是具体的业务部门，也可以是抽象的系统（此时简介受益人是组织）；R3来自于客观存在。
- 某人，这个角色在实际中有很多职能部门的人来担任，例如CTO，CIO，产品经理，用户体验师，咨询公司，外部公司等，它的职责是提出解决方案。
- 目标架构，是解决方案的一部分（重合度可以是100%），目标架构是架构理论的具象，也即架构本体。
- 传道者，负责把架构理论，架构支撑框架，架构运营策略传递到公司。
- 下面的大方框内部是支撑框架的主体。在实际运作时，这个框架最好以项目的形式运营，这样是为什么有项目经理角色存在的原因。
- 支撑框架，横向包括5层：过程框架层、内容框架层、实践指导框架层（即过程A — 过程F），角色层，能力框架层；遵循包含3大类，6个子类，列与过程框架的交叉点上最终业务目标，列于内容框架的交叉点上子业务目标列的下面节点都是对业务目标的纵向支撑。
- 过程框架包括定义了过程路径和基本里程碑，P1->P2->P3-P4是基本过程；P5表示一个反馈和改进行为。这一部分与架构定义流派的决策派是有些映射的，只是具体基本里程碑的出发点是不一样的，例如，对于产品架构来说，本体过程包含了设计-研发-测试几个行为。
- 路径P6是一个特殊，它的行为是“比较”，通过对当前架构和目标架构的比较，找出差距，从而定制计划。
- 内容框架包括需求、概念、设计、本体、环境、运行体这6个子域，每个子域都有其特殊的内容项、内容格式。这一部分与架构定义流派的组成派是有些映射的，但也不是完全匹配，但目标是一致的：描述清楚架构的构成。
- 实践指导框架，本质上是把现有的各类方法论分门别类的放到对应的列上，再提供详细的过程指导。
- 角色层，定义清晰的角色，根本目标是定义视点，架构绝对不是一个视点的产物，它是多种视点汇聚而成的综合体。每个角色也可能有多个视点，不同角色之间，可能共享视点，但偏角不同（侧重点不同）。角色是整个框架的中枢，它纵向串起了一个价值链路，形成如下场景：经过某个认知过程，角色A具有了需求能力，该能力依赖于某些领域知识A1和某些技能A2，具有该能力的角色以实践过程A为指导，产出了需求内容。横向串起了领域，领域的顺序代表了认识事物的深入，由模糊到抽象，由抽象到具体，由静态到动态。
- 能力框架表示某个角色要达到某个业务目标，需要掌握的知识和技能。能力是做事的充分条件，但不代表没有这种能力的人不能做这件事。通常，对于不具备能力的人来说，首先按照能力体系的要求学习知识，掌握一定的技能；对于组织来说，就要培养这样的人具有该角色所要求的能力；对于项目经理来说，安排人干活时，首先要评估其能力，否则就要把这一点列入风险管理。
- 项目框架，把整个支撑作为项目来运作，而不是简单的一个活动或者学习，才能够确保：高效、高质、合适成本的得到目标框架。
【作用】通过该支撑框架，能够获得如下作用：
- 定义了清晰的工作目的–解决方案、目标域、目标架构
- 完整的工作指导–过程体系
- 完整的内容指导–内容框架
- 可操作的工作内容–执行P6过程的结果
- 树立客户意识–角色层，前一阶段的结果是后一阶段的输入
- 清晰的职责划分–角色层
- 员工培养–能力框架、角色层
- 交货意识–项目框架
- 风险意识–项目框架
- 成本意识–项目框架
- 质量意识–项目框架
- 改进意识–执行P5过程的结果
- 里程碑意识–过程框架
- 单项目标的可操作性–纵向价值链路
- 自我提升指导–理论体系
好的架构，是企业的核心资产之一，如何运营好这部分资产？（没有想太明白，但它依然非常重要）
星期五, 02月 27th, 2009
领域驱动设计在SOA架构中的实践
更多内容在：
架构专栏
本着实践–阅读–思考–再实践的原则，总结一下领域驱动设计在SOA架构中的实践，关于领域模型设计自身，我建议大家阅读《领域驱动设计》一书，关于领域驱动实践的入门教程，我强烈建议阅读《领域驱动设计和开发实战》；关于领域驱动实践的再一个实践入门，我建议阅读《Domain-Driven Design in an Evolving Architecture》。2篇文章中，作者还提供了架构图，它们已经能够满足大部分应用的架构需求。
1.为什么要在SOA架构中使用领域驱动设计？之所以采用SOA，不是因为好玩，而是业务复杂性导致的，迫不得已而为之呀（可参考《SOA、服务化》栏目内的一些文章）。使用了SOA架构，不代表业务复杂性自动消失，还是从业务入手分析之，从目前广泛流行的方法学中，领域驱动设计完全符合符合这个需求，它就是为解决业务复杂性而生的。
2.职责分离。有时候，由于资源的情况，会让一个人同时承担技术架构和业务系统分析的角色，这种情况下，往往会搞的这个领域驱动设计乖乖的，简单玩玩也是无所谓了，对于较大的互联网公司，就是比较头疼的事情了，应用系统的开发者不同，这架构风格绝对会千奇百怪。因而还是要把这职责分清楚，搞一个技术架构师，再搞一个业务系统分析师。
- 技术架构师：关注与领域驱动设计在SOA架构中的技术部分，重点在“解决缓存、事务管理（包括分布式事务）、分布式接口规范、通信机制、共性系统服务的注入和应用契约、领域驱动设计风格与编程模式的确定、测试方案的确定、工具的提供、搭建可运行的环境、跨环境（分布式环境）的服务依赖策略、模型转换策略和工具的提供、集成策略”。这些东西确定下来之后，技术架构风格就完全定型，下面的工作就是把架构风格“固化”，此时有2中策略，固化为框架、固化为产品，建议在头2个项目迭代中，以框架形式提供，之后就可以考虑以产品方式提供（可参考通用技术系列文章）。有了“领域驱动”在SOA架构中的支撑框架（产品），将大大的简化业务系统分析师的工作，但距离成功还有70%的距离（只有业务成功了，才是成功），可这30%将占据80%的质量属性，严重影响全局SOA架构体系的成功。
- 业务系统分析师：关于业务，关注领域驱动设计，请千万忘记技术，相信我们的战友会解决这些问题的。
3. 领域驱动设计概念架构风格图A，该风格比较保守一下，在具体cache的使用上，有2中选择，或者领域中使用，或者仓储中使用，具体那种方式适合，要看领域模型和缓存需求，不是啥都适合通过仓储缓存。
4. 领域驱动设计概念架构风格图B，该模型的变化之处在增加了一个事件层。好处：领域模型与仓储模型、cache模型等隔离，同时提供了扩展机制；缺点：不如风格图A那么直接，容易理解，且事件层放在这儿有点不伦不类。在使用中注意几点：事件对象可以业务域统一一个，或者技术框架层统一一个；建立事件标识契约，例如领域对象的类型；保证事务，避免跨线程。
5.注意以下几点：
- 领域切分不要太小，切不可变成简单的分布式方法的调用。
- SOA重用的是服务，不是功能。
- 服务应该与需求用例对应；服务提供的方法与设计用例对应（设计用例是对需求用例的实现）。
- 领域内部的复杂度与业务能力体系相关，领域不是平面的、是树状的、是有层次的，可以用层模式来切分领域对象。
- 领域内部既有用户看见的东西，也有用户看不见的业务内能力，对外暴露的值对象信息，往往来自最上层的领域对象。
- 即使一人身兼2职，也要把自己切分开，搞技术架构时，忘记具体业务，把架构风格固化下来，请开发程序员按照这个编程模型来开发；搞领域驱动设计时，完全忘掉技术。
- 如果作为公司的架构师角色进入项目团队，那么请：走入程序员中间，走入项目中间，但不要走入业务编码中间；到这儿是获取需求，验证框架（验证架构风格），发现问题的；目标是整个SOA架构的成功，不仅仅是项目的成功。
- 服务对象层，请参考《SOA实践之：Java服务接口设计的一些实践准则》，务必形成严格的编程规范，强制遵守。
星期三, 02月 25th, 2009
开发者对互联网“产品”概念再阐述
更多内容在：
架构专栏
之前在架构术语一文中讲了产品的概念，定义如下，产品(架构内容范畴)：是一种资源，是对能力的实现。这个描述其实比较抽象，理解起来不是很容易，下面通过一个小故事来进一步阐述产品-服务-能力-功能的概念（这几个概念，看起来简单，以前我们划分了很多时间来辨析和定义，否则在做架构和设计的时候，做出来的东西也会非常模糊；在给程序员传递架构概念的时候，又讲不出一个东西到底是服务，还是功能，或者是产品；例如，我们的销售在卖东西的时候，常常会说，卖产品，卖服务，那么对于我们互联网类的公司到底啥是产品，啥是服务？难道产品==服务吗？）。
由于最近常去吃火锅，就以这个故事为题来讲讲，每一句话括弧里的内容是阐述。
客户：有吃的吗？（客户问，饭店是否有“吃”的服务，以满足客户温饱的需要。A: 这个时候，服务是概念化的。B:服务与参与者是关联的，没有参与者的服务是不存在的。）
侍者：有。（饭店有满足客户需求的能力，因而饭店提供这个服务。A:能力是服务的必要条件。B:能力承载了很多内容，知识、过程、资源。C:能力是企业内部具有的一种东西，这种东西对外表示为服务，能力可以不依赖参与者存在，它是客观存在的，具有能力不代表一定要提供服务，但要提供服务，必须具有能力。）
客户：给找个地方。（客户必须通过某种形式获取服务，也即渠道，或者连接物。A:渠道是多样的，也是必须的。B:服务必须通过某种渠道提供出去）
客户：有大锅吗？（客户选择提供服务的产品。A:产品是客观存在的。B:产品能够提供服务。C:产品是对能力的实现。）
侍者：抱歉，大锅用完了。（这款产品的有限，不是没有这款产品。A:产品需要企业提供资源来运行。B:产品依赖的资源限制了产品的可用性。）
侍者：小锅还有。（有提供同等服务的产品。）
客户：就是不太爽。（这款产品的服务质量对这类客户不是很好；但有些客户喜欢小锅。A:服务是无差别的。B:产品是细分的，或者说不同的客户对服务的限制是不同的。C:产品差异性，体现在限制的差异–或者扩展需求的差异，基本需求是不变的。D:服务质量是相对的，同样的市场，相同的业务，有人成功，有人失败，原因在于群体对服务的限制不同，质量要求不同。）
侍者开始准备。（搭建环境，把产品运行起来。A:静态的产品和动态的产品是由很大差异的。B:产品运行起来之后，它的能力才能释放出来，才能为客户提供服务。）
客户准备调料。（自助功能，该功能对大小锅是通用的。）
侍者上菜。（功能，企业内部提供的，是该产品所必须的—除非提供自主取菜服务。）
客户煮菜。（自助功能，产品的核心功能。）
客户调整火势大小。（自助功能，产品的辅助功能，但也是关键需求之一。）
客户：买单。（客户使用了该产品提供的服务，需求得到了满足，爽了。 A: 产品提供一系列的功能，这些功能围绕某个核心功能展开或者以某个过程进行，从而为客户提供服务。B:服务的过程中，可能涉及多个参与者，但核心参与者只有一个，那就是服务的发起方，其它参与者都是服务的协作方。C:能力可以细分为子能力，最终的叶子能力可以对应到功能。）
客户：能刷卡吗？
侍者：不能。（不具备这个能力，无法提供刷卡服务。A:有的能力依赖外部伙伴支持。B:外部伙伴提供的也是服务，例如本例中的刷卡服务，但该服务需要一个产品来支持，可以是：POS机器，电话银行，手机终端等。）
通过上面的小故事和下面的图示，进一步帮助理解 产品 –能力– 服务 — 功能的关系。【但需要说明的是：此处的服务，泛指业务服务，我们常讲的客户服务，可以抽象为某个产品的辅助功能。】
星期二, 02月 24th, 2009
架构术语
更多内容在：
架构专栏
架构风格：是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。
架构模式：模式的设计空间（design space）包括了特定于面向对象编程技术的实现关注点，例如类继承和接口组合，以及架构风格所带来的高层次的设计问题[。在一些情况下，架构风格的描述也被称作架构模式（architectural patterns）。然而，模式的一个主要的优点是它们能够将对象之间的相当复杂的交互协议描述为单个的抽象，其中既包括行为的约束，也包括实现的细节。总的说来，一种模式或由多种模式集成在一起的模式语言能够被看作是实现对象之间的一组预期交互的方法。换句话说，一种模式通过遵循一种固定的设计和实现选择（implementation choices）路径，定义了一个解决问题的过程。
视点：看问题的角度或方向。例如：层、组织结构、时间、数据、参与者、技术、领域、安全、性能、品质等。
视图：从某一视点看到的内容的简化描述，描述中涵盖了系统的某一 特定方面，而省略了与此无关的其他方面。
框架：架构概念的本体，可以是代码，也可以是文档，或其它制品。
架构原则：统一的规则和指导方针，针对不同的领域或层，架构原则有所不同。例如：关注点分离、松散耦合，最大化组织利益，简单，业务一致性，职责划分等。
品质属性：指架构内容的所有属性（功能属性和非功能属性）。例如：进化的相对容易程度、组件的可重用性、效率、动态扩展能力。
质量属性：是品质属性的一种，一般指等同于非功能属性。例如：性能、可伸缩性、简单性、可修改性、可见性、可靠性、易用性等。
组件(架构内容范畴)：是软件指令和内部状态的一个抽象单元，通过其接口提供对于数据的转换。
连接器(架构内容范畴)：是对于组件之间的通讯、协调或者合作进行仲裁的一种抽象机制。
数据(架构内容范畴)：是组件通过一个连接器接收或发送的信息元素。
配置(架构内容范畴):在系统的运行期间组件、连接器和数据之间的架构关系的结构。
服务(架构内容范畴)：从使用者角度看到的业务价值，通过服务，使用者需求得到满足。
能力(架构内容范畴)：做业务的基本要素或技能。例如：搞软件外包服务，那么你必须具有研发能力，管理能力等。
功能(架构内容范畴)：可操作的行为。一个服务可以通过许多个功能来实现。
产品(架构内容范畴)：是一种资源，是对能力的实现。例如：开发了搜索产品，那么就具有了搜索能力，搜索产品必须在某个环境运行，才能为客户提供搜索服务，客户通过渠道（由运行环境提供，例如：互联网，WAP，手机短信）使用功能（进行操作），经过一系列的能力发挥（产品运行），客户获得了价值。
开发者对平台-产品平台-产品线架构的探讨
平台是当前互联网的热点，大家都在想着建平台，特别是开放平台，这个Facebook，逼得大家都往这个概念上飞奔。对于我们技术人员来说，就得考虑怎么建这玩意。
探讨1：建平台，那么啥是平台？以前看到一篇文章《用平台的思想观察互联网》写的非常好。平台是一个供多方参与者获取价值诉求的环境。从这个定义中，可以分析到平台的几大要素：参与者，价值链，环境。
- 参与者：只有一个参与者，肯定没戏，原始社会不就这样吗？因而参与者必须是多个，所扮演的角色各相同，但基本上有这几类，利益输入者（换取另外一种价值），利益获得者（提供价值，换取利益），环境搭建者（维护、运营环境），游戏规则制定者（如何均衡的分配利益，满足利益获得者；如何客观的评估价值，满足利益输入者）。
- 价值链：“天下熙熙皆为利来，天下攘攘皆为利往。夫千乘之王，万家之侯，百室之君，尚犹患贫，而况匹夫“。这是平台存在的根本，也是商业性所要求的，是驱动参与者进入平台的“原力”，共产主义形式的平台目前还没看到。需要几条价值链？一般以某一核心价值链为中心，想多条也可以。
- 环境：参与者玩游戏、交换价值的地方。也是技术人员最关心的东西。
探讨2：产品平台与平台是啥关系？产品平台是平台的环境部分。在互联网领域，它首先提供容纳的能力，标识参与者的能力，支持利益获得者运行服务，支持利益输入者体验服务，支持游戏规则制定者有一只强力的手来调控价值链。对于技术人员来说，要搭建平台不是简单的一个技术平台，先得请我们的业务人员把平台的第一，第二要素搞清楚，否则失败的概念会挺高。
探讨3：开放平台与产品平台是啥关系？对于不同的平台，其开放的意义是不同的，但有一点是相同的：容许价值链的某一个点（或多个点）让第三方群体参与。例如，移动通过审批机制，允许SP参与到短信平台；Amazon开放商品供应点，允许第三方参与；淘宝开放平台的API，允许第三方提供网店的功能扩展。开放API只是开放的一种表现形式，而不是开放的本质，Amazon和移动就是很好的例证，开放的本质是价值链的开放，特别是利益获得者价值的开放，无利，开放了也没有价值。
探讨4：产品线与产品平台是啥关系？产品平台是平台的环境部分，与公司的价值链相对应；产品线是业务的实体部分，与公司的业务域相对应。一个或多个产品线可以运行在产品平台上；产品平台也可能是一个产品线。
探讨5：产品线是啥？围绕某一核心价值展开的系列产品，产品线中的产品承担的角色依据策略而各不相同，有的是核心价值的附加，有的是核心价值的放大器等等。比较典型的有:Google搜索产品线，支付宝的支付产品线。
探讨5：产品线架构与产品线是啥关系？产品线架构与平台、产品平台不具有直接关系。产品线架构是针对产品线的，为产品线里的产品提供共同的支撑，例如，共同的业务架构、共同的技术架构。产品线架构首先提供可重用的基础业务，支持产品的多样性、系列化、或形成“价值附加族”（以某一产品的核心价值为中心，研发的依赖核心价值而存在的其它产品，具有增强、放大核心价值的能力）；从技术上提供相同的基础环境、规范、工具等，简化产品的研发和缩短周期。
探讨6:如何构建产品线架构？以《架构的支撑框架和运营》一文为指导，实践之。
架构的支撑框架与运营
| 更多内容在： |
架构专栏 |
在《对架构的另类定义》一文中对架构进行了定义，虽然利用了事物本质来阐述，依然比较抽象，理解起来比较困难，因而再定义一个支撑框架。这种做法与事务研究方法是对应的：“架构定义”是概念，“支撑框架”是本体，“运营中的架构”是运动体。下图展示了这个理念：
【图示说明：】
- 第一个领域是需求域，包括R1，R2，R3。R1代表当前实际的需求；R2代表了目标，例如，企业战略指标，系统容量指标等；R3代表了当前架构，如果还没有系统，那么R3为空。R1，R2来自于受益人，此处的受益人可以是具体的业务部门，也可以是抽象的系统（此时简介受益人是组织）；R3来自于客观存在。
- 某人，这个角色在实际中有很多职能部门的人来担任，例如CTO，CIO，产品经理，用户体验师，咨询公司，外部公司等，它的职责是提出解决方案。
- 目标架构，是解决方案的一部分（重合度可以是100%），目标架构是架构理论的具象，也即架构本体。
- 传道者，负责把架构理论，架构支撑框架，架构运营策略传递到公司。
- 下面的大方框内部是支撑框架的主体。在实际运作时，这个框架最好以项目的形式运营，这样是为什么有项目经理角色存在的原因。
- 支撑框架，横向包括5层：过程框架层、内容框架层、实践指导框架层（即过程A — 过程F），角色层，能力框架层；遵循包含3大类，6个子类，列与过程框架的交叉点上最终业务目标，列于内容框架的交叉点上子业务目标列的下面节点都是对业务目标的纵向支撑。
- 过程框架包括定义了过程路径和基本里程碑，P1->P2->P3-P4是基本过程；P5表示一个反馈和改进行为。这一部分与架构定义流派的决策派是有些映射的，只是具体基本里程碑的出发点是不一样的，例如，对于产品架构来说，本体过程包含了设计-研发-测试几个行为。
- 路径P6是一个特殊，它的行为是“比较”，通过对当前架构和目标架构的比较，找出差距，从而定制计划。
- 内容框架包括需求、概念、设计、本体、环境、运行体这6个子域，每个子域都有其特殊的内容项、内容格式。这一部分与架构定义流派的组成派是有些映射的，但也不是完全匹配，但目标是一致的：描述清楚架构的构成。
- 实践指导框架，本质上是把现有的各类方法论分门别类的放到对应的列上，再提供详细的过程指导。
- 角色层，定义清晰的角色，根本目标是定义视点，架构绝对不是一个视点的产物，它是多种视点汇聚而成的综合体。每个角色也可能有多个视点，不同角色之间，可能共享视点，但偏角不同（侧重点不同）。角色是整个框架的中枢，它纵向串起了一个价值链路，形成如下场景：经过某个认知过程，角色A具有了需求能力，该能力依赖于某些领域知识A1和某些技能A2，具有该能力的角色以实践过程A为指导，产出了需求内容。横向串起了领域，领域的顺序代表了认识事物的深入，由模糊到抽象，由抽象到具体，由静态到动态。
- 能力框架表示某个角色要达到某个业务目标，需要掌握的知识和技能。能力是做事的充分条件，但不代表没有这种能力的人不能做这件事。通常，对于不具备能力的人来说，首先按照能力体系的要求学习知识，掌握一定的技能；对于组织来说，就要培养这样的人具有该角色所要求的能力；对于项目经理来说，安排人干活时，首先要评估其能力，否则就要把这一点列入风险管理。
- 项目框架，把整个支撑作为项目来运作，而不是简单的一个活动或者学习，才能够确保：高效、高质、合适成本的得到目标框架。
【作用】通过该支撑框架，能够获得如下作用：
- 定义了清晰的工作目的–解决方案、目标域、目标架构
- 完整的工作指导–过程体系
- 完整的内容指导–内容框架
- 可操作的工作内容–执行P6过程的结果
- 树立客户意识–角色层，前一阶段的结果是后一阶段的输入
- 清晰的职责划分–角色层
- 员工培养–能力框架、角色层
- 交货意识–项目框架
- 风险意识–项目框架
- 成本意识–项目框架
- 质量意识–项目框架
- 改进意识–执行P5过程的结果
- 里程碑意识–过程框架
- 单项目标的可操作性–纵向价值链路
- 自我提升指导–理论体系
好的架构，是企业的核心资产之一，如何运营好这部分资产？（没有想太明白，但它依然非常重要）
领域驱动设计在SOA架构中的实践
| 更多内容在： |
架构专栏 |
本着实践–阅读–思考–再实践的原则，总结一下领域驱动设计在SOA架构中的实践，关于领域模型设计自身，我建议大家阅读《领域驱动设计》一书，关于领域驱动实践的入门教程，我强烈建议阅读《领域驱动设计和开发实战》；关于领域驱动实践的再一个实践入门，我建议阅读《Domain-Driven Design in an Evolving Architecture》。2篇文章中，作者还提供了架构图，它们已经能够满足大部分应用的架构需求。
|
|
|
1.为什么要在SOA架构中使用领域驱动设计？之所以采用SOA，不是因为好玩，而是业务复杂性导致的，迫不得已而为之呀（可参考《SOA、服务化》栏目内的一些文章）。使用了SOA架构，不代表业务复杂性自动消失，还是从业务入手分析之，从目前广泛流行的方法学中，领域驱动设计完全符合符合这个需求，它就是为解决业务复杂性而生的。
2.职责分离。有时候，由于资源的情况，会让一个人同时承担技术架构和业务系统分析的角色，这种情况下，往往会搞的这个领域驱动设计乖乖的，简单玩玩也是无所谓了，对于较大的互联网公司，就是比较头疼的事情了，应用系统的开发者不同，这架构风格绝对会千奇百怪。因而还是要把这职责分清楚，搞一个技术架构师，再搞一个业务系统分析师。
- 技术架构师：关注与领域驱动设计在SOA架构中的技术部分，重点在“解决缓存、事务管理（包括分布式事务）、分布式接口规范、通信机制、共性系统服务的注入和应用契约、领域驱动设计风格与编程模式的确定、测试方案的确定、工具的提供、搭建可运行的环境、跨环境（分布式环境）的服务依赖策略、模型转换策略和工具的提供、集成策略”。这些东西确定下来之后，技术架构风格就完全定型，下面的工作就是把架构风格“固化”，此时有2中策略，固化为框架、固化为产品，建议在头2个项目迭代中，以框架形式提供，之后就可以考虑以产品方式提供（可参考通用技术系列文章）。有了“领域驱动”在SOA架构中的支撑框架（产品），将大大的简化业务系统分析师的工作，但距离成功还有70%的距离（只有业务成功了，才是成功），可这30%将占据80%的质量属性，严重影响全局SOA架构体系的成功。
- 业务系统分析师：关于业务，关注领域驱动设计，请千万忘记技术，相信我们的战友会解决这些问题的。
3. 领域驱动设计概念架构风格图A，该风格比较保守一下，在具体cache的使用上，有2中选择，或者领域中使用，或者仓储中使用，具体那种方式适合，要看领域模型和缓存需求，不是啥都适合通过仓储缓存。
4. 领域驱动设计概念架构风格图B，该模型的变化之处在增加了一个事件层。好处：领域模型与仓储模型、cache模型等隔离，同时提供了扩展机制；缺点：不如风格图A那么直接，容易理解，且事件层放在这儿有点不伦不类。在使用中注意几点：事件对象可以业务域统一一个，或者技术框架层统一一个；建立事件标识契约，例如领域对象的类型；保证事务，避免跨线程。
5.注意以下几点：
- 领域切分不要太小，切不可变成简单的分布式方法的调用。
- SOA重用的是服务，不是功能。
- 服务应该与需求用例对应；服务提供的方法与设计用例对应（设计用例是对需求用例的实现）。
- 领域内部的复杂度与业务能力体系相关，领域不是平面的、是树状的、是有层次的，可以用层模式来切分领域对象。
- 领域内部既有用户看见的东西，也有用户看不见的业务内能力，对外暴露的值对象信息，往往来自最上层的领域对象。
- 即使一人身兼2职，也要把自己切分开，搞技术架构时，忘记具体业务，把架构风格固化下来，请开发程序员按照这个编程模型来开发；搞领域驱动设计时，完全忘掉技术。
- 如果作为公司的架构师角色进入项目团队，那么请：走入程序员中间，走入项目中间，但不要走入业务编码中间；到这儿是获取需求，验证框架（验证架构风格），发现问题的；目标是整个SOA架构的成功，不仅仅是项目的成功。
- 服务对象层，请参考《SOA实践之：Java服务接口设计的一些实践准则》，务必形成严格的编程规范，强制遵守。
开发者对互联网“产品”概念再阐述
| 更多内容在： |
架构专栏 |
之前在架构术语一文中讲了产品的概念，定义如下，产品(架构内容范畴)：是一种资源，是对能力的实现。这个描述其实比较抽象，理解起来不是很容易，下面通过一个小故事来进一步阐述产品-服务-能力-功能的概念（这几个概念，看起来简单，以前我们划分了很多时间来辨析和定义，否则在做架构和设计的时候，做出来的东西也会非常模糊；在给程序员传递架构概念的时候，又讲不出一个东西到底是服务，还是功能，或者是产品；例如，我们的销售在卖东西的时候，常常会说，卖产品，卖服务，那么对于我们互联网类的公司到底啥是产品，啥是服务？难道产品==服务吗？）。
由于最近常去吃火锅，就以这个故事为题来讲讲，每一句话括弧里的内容是阐述。
客户：有吃的吗？（客户问，饭店是否有“吃”的服务，以满足客户温饱的需要。A: 这个时候，服务是概念化的。B:服务与参与者是关联的，没有参与者的服务是不存在的。）
侍者：有。（饭店有满足客户需求的能力，因而饭店提供这个服务。A:能力是服务的必要条件。B:能力承载了很多内容，知识、过程、资源。C:能力是企业内部具有的一种东西，这种东西对外表示为服务，能力可以不依赖参与者存在，它是客观存在的，具有能力不代表一定要提供服务，但要提供服务，必须具有能力。）
客户：给找个地方。（客户必须通过某种形式获取服务，也即渠道，或者连接物。A:渠道是多样的，也是必须的。B:服务必须通过某种渠道提供出去）
客户：有大锅吗？（客户选择提供服务的产品。A:产品是客观存在的。B:产品能够提供服务。C:产品是对能力的实现。）
侍者：抱歉，大锅用完了。（这款产品的有限，不是没有这款产品。A:产品需要企业提供资源来运行。B:产品依赖的资源限制了产品的可用性。）
侍者：小锅还有。（有提供同等服务的产品。）
客户：就是不太爽。（这款产品的服务质量对这类客户不是很好；但有些客户喜欢小锅。A:服务是无差别的。B:产品是细分的，或者说不同的客户对服务的限制是不同的。C:产品差异性，体现在限制的差异–或者扩展需求的差异，基本需求是不变的。D:服务质量是相对的，同样的市场，相同的业务，有人成功，有人失败，原因在于群体对服务的限制不同，质量要求不同。）
侍者开始准备。（搭建环境，把产品运行起来。A:静态的产品和动态的产品是由很大差异的。B:产品运行起来之后，它的能力才能释放出来，才能为客户提供服务。）
客户准备调料。（自助功能，该功能对大小锅是通用的。）
侍者上菜。（功能，企业内部提供的，是该产品所必须的—除非提供自主取菜服务。）
客户煮菜。（自助功能，产品的核心功能。）
客户调整火势大小。（自助功能，产品的辅助功能，但也是关键需求之一。）
客户：买单。（客户使用了该产品提供的服务，需求得到了满足，爽了。 A: 产品提供一系列的功能，这些功能围绕某个核心功能展开或者以某个过程进行，从而为客户提供服务。B:服务的过程中，可能涉及多个参与者，但核心参与者只有一个，那就是服务的发起方，其它参与者都是服务的协作方。C:能力可以细分为子能力，最终的叶子能力可以对应到功能。）
客户：能刷卡吗？
侍者：不能。（不具备这个能力，无法提供刷卡服务。A:有的能力依赖外部伙伴支持。B:外部伙伴提供的也是服务，例如本例中的刷卡服务，但该服务需要一个产品来支持，可以是：POS机器，电话银行，手机终端等。）
通过上面的小故事和下面的图示，进一步帮助理解 产品 –能力– 服务 — 功能的关系。【但需要说明的是：此处的服务，泛指业务服务，我们常讲的客户服务，可以抽象为某个产品的辅助功能。】
架构术语
| 更多内容在： |
架构专栏 |
架构风格：是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。
架构模式：模式的设计空间（design space）包括了特定于面向对象编程技术的实现关注点，例如类继承和接口组合，以及架构风格所带来的高层次的设计问题[。在一些情况下，架构风格的描述也被称作架构模式（architectural patterns）。然而，模式的一个主要的优点是它们能够将对象之间的相当复杂的交互协议描述为单个的抽象，其中既包括行为的约束，也包括实现的细节。总的说来，一种模式或由多种模式集成在一起的模式语言能够被看作是实现对象之间的一组预期交互的方法。换句话说，一种模式通过遵循一种固定的设计和实现选择（implementation choices）路径，定义了一个解决问题的过程。
视点：看问题的角度或方向。例如：层、组织结构、时间、数据、参与者、技术、领域、安全、性能、品质等。
视图：从某一视点看到的内容的简化描述，描述中涵盖了系统的某一 特定方面，而省略了与此无关的其他方面。
框架：架构概念的本体，可以是代码，也可以是文档，或其它制品。
架构原则：统一的规则和指导方针，针对不同的领域或层，架构原则有所不同。例如：关注点分离、松散耦合，最大化组织利益，简单，业务一致性，职责划分等。
品质属性：指架构内容的所有属性（功能属性和非功能属性）。例如：进化的相对容易程度、组件的可重用性、效率、动态扩展能力。
质量属性：是品质属性的一种，一般指等同于非功能属性。例如：性能、可伸缩性、简单性、可修改性、可见性、可靠性、易用性等。
组件(架构内容范畴)：是软件指令和内部状态的一个抽象单元，通过其接口提供对于数据的转换。
连接器(架构内容范畴)：是对于组件之间的通讯、协调或者合作进行仲裁的一种抽象机制。
数据(架构内容范畴)：是组件通过一个连接器接收或发送的信息元素。
配置(架构内容范畴):在系统的运行期间组件、连接器和数据之间的架构关系的结构。
服务(架构内容范畴)：从使用者角度看到的业务价值，通过服务，使用者需求得到满足。
能力(架构内容范畴)：做业务的基本要素或技能。例如：搞软件外包服务，那么你必须具有研发能力，管理能力等。
功能(架构内容范畴)：可操作的行为。一个服务可以通过许多个功能来实现。
产品(架构内容范畴)：是一种资源，是对能力的实现。例如：开发了搜索产品，那么就具有了搜索能力，搜索产品必须在某个环境运行，才能为客户提供搜索服务，客户通过渠道（由运行环境提供，例如：互联网，WAP，手机短信）使用功能（进行操作），经过一系列的能力发挥（产品运行），客户获得了价值。
