采访一个成功的CIO
为使你简单了解如何选择正确的架构，接下来让我们穿越到未来和 SaaSOvation公司的CIO谈谈。SaaSOvation公司一开始是很寒碜的，但是正确的架构选择帮助他们一步一步走向了成功。让我们接通TechMoney节目的主持人MariaFinance-Ilmundo ...
Maria: 今晚，我将独家采访SaaSOvation公司的CIO, Mitchell Williams。我们将继续“认识你的架构风格”系列。今晚的主题是如何正确地选择架构。欢迎Mitchell。
Mitchell: 非常高兴又来到这里，Maria。
Maria: 你可以给我们讲讲在你项目的早些时候所采用的架构吗，以及为什么会采用这些架构？
Mitchell: 当然。大家可能不会相信，我们一开始打算开发桌面应用程序，将数据保存在中央数据库。当时我们采用了分层架构。
Maria: 这有用吗？
Mitchell: 我认为是有用的，特别是我们只处理单个应用层，外加中央数据库。这是一种简单的客户端-服务器风格。
Maria: 但是后来你们改变了架构，是吗？
Mitchell: 是的。我们有了新的合作伙伴，然后双方决定采用SaaS的订阅模型。我们募集到了充足的资金，同时我们决定在开发敏捷喷目管理系统之前，先开发一套协作工具。这有两方面的好处，一方面，我们加入了火热的协作工具市场，另一方面又为将来的敏捷项目管理系统提供了附加功能。你知道，在软件项目中使用协作工具可以在很大程度上提高交付能力。
Maria: 有意思。这样的决定给你们带来了什么？
Mitchell: 随着软件复杂性的增加，我们需要引入单元测试和功能测试来保证软件质量。为了做到这一点，我们在分层架构中使用了依赖倒置原则(DependencyInversion Principle, DIP)。这是非常重要的，这样我们可以在测试中轻易地替换掉UI层和基础设施层，而将关注点放在应用程序和领域逻辑上。事实上，我们得以单独地开发U丨组件而不用考虑数据持久化。DIP并没有彻底改变系统的分层架构，团队成员也很接受这种方式。
Maria:哇，将UI与持久化真正分离！这看来是有风险的。这样难吗？
Mitchell:其实也不是特别难。事实证明，DDD的战术模式并没有伤及我们。由于我们采用了聚合模式和资源库，在开发时我们可以采用内存持久化，因为我们使用了相同的资源库接口，之后我们又可以方便地切换到其他持久化机制。
Maria: 帅呆啦。
Mitchell: 嗯。
Maria: 然后呢？
Mitchell: 然后就万事大吉啦。我们成功地交付了CollabOvation和 ProjectOvation,并且开始盈利。
Maria: 哦，原来如此。
Mitchell: 请不要搞错了。之后我们决定支持移动设备，因为移动终端太火了。这样我们需要使用REST。订阅用户开始提出诸如联合身份验证等需求，再比如复杂的项目和时间管理等工具。
Maria: 神奇！这样看来火的不只是移动设备，你能继续谈谈吗？
Mitchell: 开发团队决定转向六边形架构以应对新需求。他们发现端口和适配器这种方式可以满足要求。同时他们决定采用新的输出端口类型，比如像NoSQL和消息机制等，以上这些都需要云计算的支持。
Maria: 你们当时有信心吗？
Mitchell: 当然。
Maria: 佩服。一旦你没有被击倒，那么你所做的选择将双倍地补偿你。
Mitchell: 非常对。那时我们每个月都有好几百个新租户。我们添加了一个服务将协作工具中的遗留数据迁移到云上。开发团队决定采用Mule’s CollectionAggregator,通过SOA的方式来聚合数据。
Maria: 哦，这样看来，你们不是为了使用SOA而使用SOA,而是在真正需要时才使用的。完美！在行业中我们还没有看到如此成功的例子。
Mitchell: 是的，Maria。这也确实是我们一直采用的方式，也是我们的成功范式。比如，在整个开发过程中，我们及时地引入了TrackOvation。这是一个用于跟踪defect的软件工具，它与ProjectOvation集成起来使用。随着ProjectOvation功能的增加，软件界面也越来越复杂。产品负责人的管理界面上堆满了有关项目产品和defect的各种信息。由于不同的人对界面风格有不同的偏好，这使得界面管理更加复杂了。另外，我们还需要支持移动设备。这时，开发团队考虑加入CQRS架构模式。
Maria: CQRS?这是不是太复杂了？我们还是尽量远离它吧。
Mitchell: 不，一旦团队有合理的理由使用CQRS来减少命令和查询之间的摩擦冲突，他们就会不再回头了。
Maria: 是的。那时是不是正值订阅用户开始要求分布式处理功能？
Mitchell: 对。如果我们不能在这一点上见招拆招，那不久我们就会被复杂性所淹没。有些功能需要一系列的分布式处理过程，ProjectOvation可不想让用户久等。他们引入了一套完整的事件驱动架构，使用管道和过滤器(Pipe and Filter)模式来完成此功能。
Maria: 但这并不是你们解决复杂性的终点，是吗？
Mitchell: 嗯，解决复杂性是没有终点的。然而，如果你拥有一个优秀的团队，解决复杂性就变得简单多了。事实上，事件驱动架构可以大大地简化系统的复杂性。
Maria: 对，我们继续。接下来是我最喜欢的部分。你知道...
Mitchell: 正确的架构使得我们急速成长壮大，以致于RoaringCloud在收购我们时给出的价格为...嗯，这是一个记录。
Maria: 绝对是个记录，每股50美元，一共30个亿！
Mitchell: 你的记忆力真好啊！好的架构对集成也有促进作用。RoaringCloud 向ProjectOvation迁移了大量的订阅用户，这对ProjectOvation来说是一个很大的压力。于是我们将管道和过滤器分布化和并行化，这需要新加入长时处理过程(long-running process)，有时也加Sagas。
Maria: 不错。这好玩吗？
Mitchell: 确实很好玩。
Maria: 并且似乎这种趣味永远不会消失，好戏还在后头。
Mitchell: 你知道的。由于RoaringCloud在业界处于垄断地位，政府已经开始整顿这个行业了。新出台的法律要求RoaringCloud跟踪对系统的每一次改变。事实上，解决这个问题的最好方式便是事件源(Event Sourcing)。
Maria: 这太不可思议了，太……太不可思议了。
Mitchell: 应该这么说：这是一个太不可思议的好问题。
Maria: 最让我感到惊讶的是，这么多年来，你们系统的核心始终是基于DDD 的。显然，DDD没有伤害你们，也正是因为采用了DDD，你们才得以免除艮多困难。
Mitchell: 事实上恰恰相反。我相信是因为我们及早地采用了DDD，然后花时间彻底地了解了 DDD才使得我们应对业务的重重困难，最终取得胜利。
Maria: 好吧，我们就聊到这里吧。再次感谢你，Mitchell。至此，我们学到了如何选择正确的架构。这里是“认识你的架构风格。”
Mitchell: 这是我的荣幸，Maria。非常感谢你能邀请我。
以上的采访为我们展示了如何选择正确的架构，并且如何及时地采用这些架构，我们将在接下来的章节中做详细讲解。