架构

建筑应该反映时代特征与地理特征，同时追求永恒。—Frank Gehry

DDD的一大好处便是它并不需要使用特定的架构。由于核心域(2)位于限界上下文(2)中，我们可以在整个系统中使用多种风格的架构¹。有些架构包围着领域模型，能够全局性地影响系统，而有些架构则满足了某些特定的需求。我们的目标是选择适合于自己的架构和架构模式。

在选择架构风格和架构模式时，我们应该将软件质量考虑在内，而同时，避免滥用架构风格和架构模式也是重要的。质量驱动的架构选择是种风险驱动方式[Fairbanks]，即我们采用的架构是用来减少失败风险的，而不是增加失败风险。因此，我们必须对每种架构做出正确的评估。

对架构风格和模式的选择受到功能需求的限制，比如用例或用户故事。换句话说，在没有功能需求的情况下，我们是不能对软件质量做出评判的，亦不能做出正确的架构选择。这也说明用例驱动架构在当今的软件开发中依然适用。

本章学习路线图

• 听听SaaSOvation的CIO是如何做项目回顾的。
• 学习使用依赖注入原则(DIP)和六边形(Hexagonal)架构来改进分层架构 (Layers Architecture)
• 学习六边形架构对SOA和REST的支持。
• 学习数据网织(DataFabric)或基于网格的分布式缓存(Grid-Based Distributed Cache)和事件驱动风格。
• 学习DDD世界的新架构模式一CQRS。
• 学习SaaSOvation所采用的架构。

¹. 本章是关于架构风格、应用架构和架构模式的。架构风格阐述如何实现某种架构，而架构模式则关注一种架构中的某个方面，架构模式比设计模式更加宽泛。我建议不用过于计较这两者的区别，你只需要明白，DDD可以存在于多种架构中。 ↩

架构并不酷

本章讲到的架构风格和架构模式并不是什么“很酷”的工具以致于我们应该处处使用。我们应该在有需要时，在能够降低失败风险时才采用这些架构。

[Evans]将关注重点放在了分层架构上，如此一来.SaaSOvation得出结论：只有采用分层架构时.DDD才是有效的。后来，团队花了不少时间才了解到.即便在[Evans]那个分层架构横行的时代.DDD的适用性也比他们所想象的要强。

当然，分层架构的原则依然可以作为我们的决策指导，但是我们不会止步不前，我们将在必要时采用更现代的架构和模式，这也意味着DDD的用途是非常广阔的。

值得肯定的是，SaaSOvation并不需要使用所有的架构，但是团队需要在众多架构中做出正确的选择。