从蚂蚁金服看更为贴近业务的架构思维

开年技术盛宴「大风起兮：蚂蚁金服|msup技术开放日」将于2016年03月12日在成都召开。我们将会采访一些与会讲师，谈谈他们将在会上分享的内容。

本期我们采访的讲师是来自蚂蚁金服的高级技术专家、支付核算技术部负责人于君泽。花名右军，蚂蚁金服成都研发中心技术团队创建者之一，先后负责或参与过转账类业务、账单类业务、社区支付、开放平台、支付平台、资金核算平台、类营销类支付工具的建设；之前有数年电信业务研发经验，涉及BSS|OSS|针对性营销等平台。

Who am I

我在蚂蚁金服平台这边的支付核算技术部，base地点在成都。我们团队主要做有关支付、核算部分平台的研发工作。我个人主要focus在几件事：

1. 根据公司和部门战略，设定有足够挑战性的目标并保障达成；

2. 重点方向的把握，重点目标的贯穿；

3. 创造良好的工程师文化环境、招聘和培养。

架构、设计模式与框架

架构是一种思考模式，是一种方法体系，迭代演进、按需、不做大设计等等都是其精神内核。关于什么是架构有2个流派，一是决策派，一是组成派。

我认为无论什么业务，什么平台，架构都要服务于对应的客户价值，也就是「以终为始」。

框架（Framework）按百度百科的定义，是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。

设计模式是实现层的概念， 设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

架构设计最困难的地方，何为「以始为终」

架构设计最困难的地方是对问题域的分析和识别，如识别不正确就贸然进行后续工作，无异走上一条不归路--死亡之旅。

以终为始的架构设计原则一句话概括就是为业务价值服务，不能为做架构而做架构。架构设计作为统领全局的方法体系，自然要贯彻始终的最好需求的真实反映、衡量标准的提炼（SLA）、端到端的运行处理、业务运营能力来支撑目标架构的实现，从而支撑当下需求和为远期需求发展做好可能的准备。具体分为3个层次，11个观点。如下图所示：

只画架构图的架构师不是好架构师

架构是一种思考模式，架构本身也是演进的。架构不仅仅是画ppt。有一个传统设备生产软件的研发主管曾和我交流，他的问题是系统架构师就是PPT架构师——只写PPT，然后交给研发团队实现，之后就不管了，所以缺乏一个从头到尾负责的架构师。我的想法是，架构不只是规划，还包括架构实施，就是架构到设计、编码过程是否走样。我们要求架构师带着业务研发一起干，ppt是中间结果，不是产出，只有交付给客户的才是产出。当然,从组织到绩效考核也得有配套变化。

架构师的成长

王福强在文章中分享过架构师需要有前瞻性眼光、系统性的思考、开放性的心态，我深表认同。架构和软件技术都以服务业务为目标，这里的前瞻性和系统性都需要归结到tradeoff，为了技术而技术肯定会失败的。心态开放，举一个例子说明，见过聪颖的架构师，每次争论都有很强的气势；也见过有观点、有实力的架构师，同时也是虚怀若谷的架构师，在信息交流中，说服不是终极目标，应该还有收获和吸收，或者增强自己知识体系，或者收获到不一样的思路或方案。

有信息披露，早在1960年代，诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来，部分由于在 Rational Software Corporation 和微软内部的相关活动开展，而软件架构的概念开始流行开来，架构师的概念也就应运而生。

但如何成为架构师，架构师需要掌握那些技能、架构的方法体系除了来自一些书本的经验总结以及具体摸爬滚打，未见更体系的教育模式。就国内而言，架构师和架构方法的原创书籍就更少了。架构师的培养是作坊式的模式，一家企业内部培养，培养周期长。如今通过技术社群、同行交流、学习先进方法经验等模型有望提升培养的品质。

增强领域建模能力以应对业务变化的挑战

领域模型是业务领域的自然反映，是分析范畴而非设计范畴的概念。我们有一个平台「姑且称之为X平台」，开发超过3年了，其中孵化的业务形态超过10种以上。我们常常把繁复的接入或者适配归咎为业务的变更、业务模式创新、玩法多样，付出的成本是平台代码的重构，接入顺畅度受到挑战。经过最近2次新业务形态的接入，我们几乎一致认为之前的领域模型是有些不恰当的表达和识别，导致实现阶段耦合度比较高。

引用一位团队同学的说法是， 在业务快速发展，业务模式瞬息万变的时代，如何拥有一颗真正的"设计"者的头脑，而不仅仅是做一个能工巧匠，是我们需要去思考的。系统分析手段、行业知识学习、领域建模能力也都需要增强。

领域建模中的「模」究竟是什么

业界有一种定义，领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。以我所服务的电商网站举例，商品、订单、购物车都是领域模型，因为他们是客观存在的，同时这些模型直接存在某种联系。

由于分析者对于客观世界的认知差异，得到的模型也是不同的。比如古人认为地球是宇宙的中心，是静止不动的，而其它的星球都环绕着地球而运行；而哥白尼提出的“日心说”，有力地打破了长期以来居于宗教统治地位的“地心说”，实现了天文学的根本变革。

领域建模可以参照的方法论以笔者观点有几种：一是彩色建模，由Peter Coad提出；一是DDD，由Eric Evans著书立说；一是由Martin Fowler所著的分析模式，为多行业领域经验的精华沉淀。同时参照不同行业的规范和信息架构，亦是建模方法的指导。

模型到代码如何转换

模型到代码的转换，此前有一种思路叫MDA，MDA所提出的解决方案是将企业及应用系统与实现技术平台分离，且以统一建模语言UML来表达与平台无关的PIM(Platform Independent Model)，然后再设计出适用于特定平台的模型PSM（Platform Specific Model）。

这一目标过于理性，实际在大规模研发中很少成功应用，比如互联网研发，sql性能是频繁调优的，包括异步化、批处理一些技术手段的使用。在这些优化中，业务模型可能并没有变化，但是实现却发生了重大变化；另外，由于模型和实现都会不断演进，涉及到2个循环在迭代中版本的管理，自动生成代码和手工代码的管理等，对于不同框架的工具支持等。

DDD思想提出后（ 2004年著名建模专家Eric Evans发表了他最具影响力的著名书籍：《Domain-Driven Design –Tackling Complexity in the Heart of Software》），对模型到实现代码的转换在模型泛型、服务模型、设计层次等方面提供一些模板参考。

模型的分析识别到良好的设计实现，可以让软件拥有一定的可扩展性、可维护性，以及高性能要求。在分析和设计实现还有一个鸿沟需要跨越，就是用技术手段校正，数据库表并非领域模型的简单映射，会考虑使用缓存、数据冗余解决性能的问题。

DDD和重构都可以提高扩展性但思路不同

DDD是一种从模型到实现的方法，辅以ATDD或者实例化需求的手段，可以尽量保障在产品初期就能达到「做正确的事」， 前面有聊到我们亲身经历过对于领域模型识别不够清晰而导致商户风险控制和用户侧耦合的case。

重构是对抗「腐化」的方法，重构是就是在外在行为不变的情况下通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和可维护性。

DDD和重构都可以对提高软件的扩展性、可维护性做出一定的贡献。

即将在开放日分享的话题

我分享的topic 就是领域建模方法，期望通过具体case解析常见的领域建模方法，发掘一些分析原则、并能从实现验证的角度反刍分析建模环节。

值得一提的是，由蚂蚁金服和msup联合举办的技术开放日将于03月12日在成都举行，本次开放日涵盖：领域建模、SOA、搜索系统、SaaS、支付宝红包、TDD、用户体验、SLA、大数据等诸多议题，届时来自蚂蚁金服的讲师将分享所在领域的最佳实践。【点击这里报名】

本文根据开放日讲师采访原创首发，转载或节选内容前需获授权。同时，也欢迎更多企业、社区与TOP100公众账号展开内容合作，更欢迎您成为原创作者。更多内容合作请发邮件至wow@top100summit.com，我们期待认识你：）