课程费用：5800 元/人

课程简介：
软件架构并非架构师闭门造车完成的作品，而是整个开发团队积极与客户沟通协作，在树立了共同的系统愿景与目标之后，由架构师基于架构原则与架构方法，在满足软件系统功能目标的前提下，进行的一次设计历险。之所以称为“历险”，是因为软件架构从来都不能一蹴而就，在这个过程中可能会经历诸多风险和未知的变化，如大海航行可能会遭遇的暗礁与风暴。是否能够到达成功彼岸，除了需要架构师卓越的架构能力，还需要整个开发团队遵循系统的架构原则与约束，并能在面对紧急时刻，调整系统的架构方向。 于是，设计软件架构就面临两大难题： o 如何明确客户的需求，并将需求没有偏差，或较小偏差地转化为架构？ o 如何设计恰如其分的架构，从而在不浪费资源的情况下，具有掌控变化与风险的能力？ 本地课程引入的可视化架构设计策略， 正是解决第一个问题的有效方案，它通过直观而又具备协作能力的方式，引导架构师与整个团队包括客户积极参与到软件架构过程中来，并通过场景图、上下文映射图、四色法、设计画布、架构雷达等诸多可视化手段，让架构变成为一种沟通交流的视觉工具。换言之，这是一种体验式的架构设计。它同样遵循经典的架构原则与设计方法，但却可以让这些原则与方法活跃在彩色图形上，让团队协作成为可能，让架构结果更加直观，从而避免了沟通上的误差与分歧，使得团队能够迅速就架构内容达成一致。 架构本身是复杂的，但它的呈现却必须足够清晰简单，易于理解，因为架构本身是作为开发团队交流基础而存在。要有效地解决前面提出的第二个问题，就需要搭建一个具备简单、一致和自治特色的整洁架构。基于此，整个培训将围绕Clean Architecture的思想，重点讲解六边形架构以及诸多主流架构风格，再通过风险驱动模型来指导整个架构过程。

课程核心内容：
1.面向对象分析与设计 2.领域驱动设计 3.场景驱动设计 4.四色建模 5.六边形架构模式 6.面向服务架构 7.基于消息的分布式架构 8.数据为中心的软件架构 9.Map Reduce 10.RESTful架构 11.CQRS架构 12.SaaS架构 13.风险驱动模型 14.Clean Architecture 15.RUP 4+1架构视图

可视化架构设计手段包括：
1.商业模型画布 2.体验地图 3.流程图 4.设计环图 5.设计画布 6.Value Sliders 7.Attributes Matrix 8.技术债雷达图 9.约束推导图 10.依赖沉淀图 11.上下文映射图 12.六边形架构图 13.四色建模 14.场景图 15.设计鱼骨图 16.基于FutureBackwards的风险评估模型 17.架构雷达图

讲解的技术与框架包括：
1.NHibernate 2.Entity Framework 3.Spring.NET 4.ASP.NET MVC 5.ASP.NET Web API 6.WCF 7.MSMQ 8.Rabbit MQ

内容
第一单元
卓越软件设计
1、设计要素、原则与方法
架构能力的基础是要具备良好的软件设计能力，这就需要掌握了解软件的设计要素和基本原则。这些设计要素包括面向对象设计的封装、继承与封装，SOLID设计原则，并建立以角色、职责与协作为中心的职责驱动设计思想，同时，通过提高设计者的抽象能力，以精化与简化设计模型，支持可扩展设计。
2、场景驱动设计模型
场景驱动设计的核心在于识别场景，它需要设计者结合具体的业务场景，分析业务流程，以此驱动出用例；再以用例驱动对业务逻辑的建模。场景驱动设计的核心模型为6W模型，即Who，Why，When，What，Where与hoW。它将对应职责模型的业务价值、业务功能与业务实现，并从角色的角度思考对象之间的协作以及设计边界。
可视化演练：设计环图

第二单元
场景驱动设计
1、绘制场景图
架构师需要具备良好的业务分析能力和领域建模能力，并通过运用建模方法将业务需求逐步转换为架构设计，然后逐步搭建架构基础设施，从而建立整个软件系统的基础架构。
本部分内容将介绍绘制场景图的可视化手段。它支持对业务需求进行分析与建模，同时也是场景驱动设计的入口。场景图通过模拟业务流程，识别出整个场景的主要参与角色，主要行动步骤；同时，还有助于识别出与目标系统进行协作的外部系统。
绘制场景图的方法包括Business Model Canvas（商业模型画布）、体验地图与流程图。
可视化演练：绘制电子商务系统的场景图
2、限界上下文
若要进行领域建模，并将业务需求逐步演化为架构设计，则需要引入DDD（领域驱动设计）的战略设计作为指导。场景图与限界上下文可以很好地结合，帮助架构师很好地识别各个子领域的概念边界与设计边界。如此则可以运用“分而治之”的思想识别出整个系统的业务逻辑边界与物理边界
可视化演练：识别电子商务系统的限界上下文
3、领域模型
通过限界上下文，可以帮助我们分析系统的领域模型，包括系统的核心领域与子领域。确定系统的核心领域与子领域可以帮助架构师合理分配资源（包括时间资源与人力资源）。而对子领域的进一步识别，可以帮助架构师更好地识别可重用资源，包括可重用的功能模块，确定技术栈，决定构建还是购买的架构战略。
可视化演练：四色建模法
4、上下文映射图
本部分内容会讲解限界上下文之间主要存在的组织模式与集成模式，这其中包括防腐层，开放服务调用等。利用上下文映射图，有助于识别上下文之间的关系，思考处于上下文内领域模型之间的通信方式，从而帮助架构师驱动出最终的应用逻辑架构。
可视化演练：电子商务系统的应用逻辑架构

第三单元
六边形架构与SOA
1、六边形架构
虽然分层架构仍然是运用最为广泛的架构模式，同时更是诸多架构模式的基础，但它已不足以描述越来越复杂的分布式系统架构。由Cockburn提出的六边形架构（HexagonalArchitecture）是一种具有对称性特征的架构风格。在这种架构中，不同的客户通过“平等”的方式与系统交互。该架构中存在两个区域，分别是“外部区域”和“内部区域”。这种界定了明确内外边界的架构风格，更有利于架构师实现关注点分离并将关注重心放在适配器与通信端口上。
可视化演练：六边形架构的通信边界
案例：大型金融系统的客户管理
2、SOA
六边形架构能够更好地支持SOA架构。本部分内容主要关注SOA设计原则，帮助架构师更好地设计系统的服务，明确系统之间的契约。
案例：全球酒店在线预订系统
案例：金融系统的SOA架构演化

第四单位
架构技术与实践
无论架构风格与模式多么完美与优雅，最终还是需要运用具体的架构技术才能落地。系统的整体架构虽然应该尽量避免与具体技术解耦，但架构师选择的技术栈仍然不可避免地会影响到系统的架构质量。本部分内容会结合具体的技术平台和技术，引入大量案例来讲解架构技术的实施，以提供在该平台下的最佳实践。
1、持久层与ORM
软件对数据的访问与管理应集中在持久层，从而解除与业务逻辑之间的耦合。目前在企业软件系统中，仍然使用更广泛的还是关系型数据库，这就需要实现对象与关系之间的映射，即运用ORM技术，用以把对象模型表示的对象映射到基于SQL 的关系模型数据结构中去。
Java常用的ORM框架主要是Hibernate。本部分内容将结合Hibernate框架深入剖析ORM的实现机制，同时讲解它的核心架构与核心组件，以及运用ORM框架的最佳实践。
案例：医疗系统对Hibernate的运用
2、基础设施层与消息队列
大多数企业级软件系统都是分布式软件系统，一种常见的架构风格就是基于消息的分布式架构，它通过引入消息队列中间件来实现系统跨进程和机器之间的通信，同时更好地支持系统的异步处理。本部分将介绍该架构风格中常用的消息模式，并重点讲解Spring AMQP与RabbitMQ消息中间件。
案例：制造工业的基于消息的分布式架构
案例：金融系统的Message Broker
3、领域层与IoC
除了合理的领域建模之外，架构师还需要引入IoC框架来管理系统各个对象之间的依赖。Java平台下，最为常用的IoC框架自然是SpringFramework，当然也包括轻量级的Guice。本部分内容将深入剖析IoC的实现机制，介绍Spring与Guice的核心架构与设计思想，同时引入对内核模式的思考。
4、表现层与MVC
软件系统的表现层已经变得越来越重要，因为它是直接吸引用户，提供用户体验的接口。表现层的设计模式主要是MVC模式以及它的一些变种。在Java平台下，常见的MVC框架为Spring MVC和Struts 2。本部分内容将对比Ruby onRails与SpringMVC，以加深理解MVC模式的核心思想与执行流程。同 时，还将结合真实案例讲解表现层设计的最佳实践。
案例：医疗系统的表现层设计（MC+JSON+VC）
5、服务层与Web服务
服务层提供了粗粒度的服务契约面向调用的客户端，这种分布式服务通常被构建为Web服务。.NET的WCF将传统的RPC与Web服务、消息队列等多种分布式模型集成起来，提供了统一的编程模型。本部分内容主要介绍了WCF的核心概念与架构，以及在项目中的运用。
6、服务层与REST服务
在服务层设计中，REST服务得到了越来越广泛地运用。.NET在ASP.NET MVC的基础上进一步强化了对REST的支持，定义了ASP.NET Web API。相比较于Web服务而言，REST服务更符合HTTP的编程模型，在很好地利用了HTTP服务接口的同时，还得到了很大程度的简化。

第五单元
架构模型
1、软件架构活动
本部分内容介绍了架构活动与其他开发活动之间的关系，探讨了架构师角色与架构的关系。
2、架构视图
在架构设计中，通常运用“视图”的概念对整个系统进行分解。通过不同涉众不同角色的不同观察视角，对系统进行划分。本部分将主要介绍Christine提出的架构视图剖析以及RUP 4+1视图。
案例：LSVT 4+1视图架构规格说明书
3、架构风格
REST架构风格：REST描述了Web作为一个分布式超媒体的应用，相互链接的资源通过交换代表资源状态的表述来进行通信。它是WEB系统架构运用最为广泛的架构风格。案例分析：订单管理系统的REST架构
基于消息的分布式架构：通过使用基于消息的中间件完成消息的发送与接收，从而实现系统之间的集成，以及业务处理的异步模型。
数据为中心的软件架构：介绍数据管理系统的三个执行步骤，并以此为基础讲解通常以数据为中心的软件架构风格。案例分析：Twitter数据管理与分析
CQRS风格：即命令查询职责分离（Command Query Responsibility Segregation），它结合了消息处理、事件处理的架构风格，是对多种设计模式的综合运用，适用于处理读写比例高，需要支持可伸缩性的大型系统。案例：AxonFramework对CQRS的支持 软件即服务的架构：介绍基于元数据和多租户的SaaS架构，分析了它与普通架构在基础设施层的主要区别，讲解了SaaS架构的核心原理与主要的构建模块。案例分析：基于Jasper Server的EISaaS架构

第六单元
Clean Architecture
1、Clean Architecture
Clean Architecture提出的模型是一个可测试的模型，无需依赖于任何基础设施就可以对它进行测试，只需通过边界对象发送和接收对应的数据结构即可。它们都遵循稳定依赖原则 ，不对变化或易于变化的事物形成依赖。
2、Clean Architecture的核心价值
设计简单的架构：通过清晰地表达设计意图，以简化系统的整体架构，并有利于设计者与开发者之间的沟通。同时，保证系统足够小，促进恰如其分的架构设计。遵循“关注点分离”的架构原则，将架构的分离策略分为纵横分离与内外分离。
设计一致的架构：保持设计风格的一致性，针对不同场景做出正确的架构决策。同时，还需要保持概念的一致性，以及解决方案的一致性。针对产品线系统，则可以通过制定路线图，作为保证一致架构的高层蓝图。
设计自治的架构：保证系统的核心组件具有如下特征：最小完备特征，自我履行特征，稳定空间特征以及独立进化特征。
3、运用Clean Architecture
演练：运用Clean Architecture思想对仓库管理流程控制系统进行架构设计

第七单元
风险驱动模型
风险驱动模型主要关注软件系统的质量属性，通过识别风险来逐步驱动软件架构设计，它强调进行恰如其分的架构设计。
1、风险驱动设计的过程
风险驱动设计的过程分为三个步骤，即识别风险，并对风险排定优先级；选择和运用适当的软件技术来降低风险；评估风险是否得到降低。
案例：RackSpace架构的演进
2、风险评估模型
评估风险并非只是架构师的职责，而应该是整个团队包括客户共同参与的结果。本部分将引入可视化的Future Backwards方法，引导团队搭建软件系统的风险评估模型。
可视化演练：Value Sliders、 风险驱动模型
3、约束对架构的驱动
除了风险之外，我们也可以通过识别一些架构约束（约束的识别是通过与客户的充分沟通，从质量属性的角度来分析），并将其作为一种驱动力来逐步改进或者调整架构。
技术债务也可以看做是另一种设计约束，我们需要随时更新整个项目的技术债务，并制定相应的计划去解决这些技术债务，从而进一步优化软件系统的整体架构。
案例：约束对REST架构风格的设计驱动
可视化演练：技术债雷达图、架构雷达图

讲师介绍：
Bruce Zhang —— 高级咨询师，软件架构师，敏捷教练

Bruce Zhang，拥有近10年的软件开发与架构设计经验，主要专注于软件架构、设计模式、领域驱动设计和敏捷开发实践。工作期间，在多个项目担任了软件架构 师，敏捷教练等角色，并曾经连续四届荣获微软最有价值专家。Bruce熟悉各种开发语言平台，包括Java、C#、Ruby以及Scala等，具有丰富的 企业软件系统和分布式开发经验。他作为咨询师和培训师，多次为惠普、可口可乐、摩托罗拉、第九城市、CA、携程等企业提供过咨询与培训服务，并翻译了和编 写多部著作。