第4章　架构

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

—Frank Gehry

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

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

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

本章学习路线图

• 听听SaaSOvation的CIO是如何做项目回顾的。

• 学习使用依赖注入原则（DIP）和六边形（Hexagonal）架构来改进分层架构（Layers Architecture）。

• 学习六边形架构对SOA和REST的支持。

• •学习数据网织（DataFabric）或基于网格的分布式缓存（Grid-Based Distributed Cache）和事件驱动风格。

• 学习DDD世界的新架构模式——CQRS。

• 学习SaaSOvation所采用的架构。

架构并不酷

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

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

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

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