在本篇文章中，将介绍以领域为中心的架构以及它和传统的以数据为中心的架构之间的区别和联系。之所以写这篇文章，是为了给DDD分层架构做一些补充说明，以便更好地了解它的前因后果。
众所周知，在人类科学史上，对于宇宙运行方式的讨论，有过两大学说，即“地心说”和“日心说”。今天我们都知道日心说才是科学的，地球和行星围绕着太阳转，大概幼儿园的小朋友也知道这是基本的常识。不过，在数百年前，坚持日心说可能要被处以极刑。
人类数百年来对于宇宙运行认知的变化，恰似数十年来对软件架构认知的变化。日心说取代了地心说，以领域为中心的架构也正在逐步成为主流。
当然，软件架构思想的变迁，也不完全与人类对宇宙认知的变迁相同，毕竟“地心说”完全是错误的。但是，软件架构中没有绝对的正确或错误。以数据为中心的软件架构，也并非一无是处。客观地说，它的诞生和流行有着历史的原因，甚至今天仍有用武之地，只不过在某些复杂业务中，它有着一定的局限性。
在以数据为中心的架构中，它的关键是用户界面层（见下图），业务逻辑层和数据访问层围绕着数据库旋转。因此，数据库是名副其实的架构中心。在这样的架构中，你不必太在意对业务逻辑层的设计。换言之，无论业务逻辑层的代码如何堆砌，数据落库无误即可。这种场面看起来似乎耳熟能详，但实际正是如此。不要误会，这里没有贬低的意思。只是说，如果你的业务逻辑较为复杂，而你又使用了以数据为中心的架构，那么你可能要重新审视你的架构了。
那么，从以数据为中心的架构到以领域为中心的架构，人们审视架构的视角是如何变化的呢？原因可能有很多，行业的老专家、《敏捷软件开发》的作者 Robert C. Martin（Bob大叔） 曾经说过一句话：
The first concern of the architect is to make sure that the house is usable, it is not to ensure that the house is made of brick.
大叔拿建筑师造房子来举例子。对于建筑师来说，造房子最关键的是什么呢？材料是砖头还是木头？显然不是，对于一所房屋来说，最关键的是它要可用，这是根本。否则建它干什么呢？至于用什么材料、选什么样的装修风格，那些都不过是细节。
这个例子牵扯出了架构中的两个重要概念，即根本（Essential）和细节（Detail）。在一个架构中如果理不清什么是根本，什么只是细节，不能把它们放在合适的位置，那么无异于本末倒置。对于房子来说，“可用”是根本，“砖头”、“装修”不过是它实现的一个细节，除了砖头还可以用木头嘛！同样，对于汽车来说，“可靠、安全”才是它的根本，至于是电动还是燃油，不过是它不同的实现。
如此，再回头来看以数据为中心的软件架构就会发现，它的问题在于搞错了根本。在企业架构中，“业务逻辑”才是根本，数据库作为一种存储方式，不过是承载业务数据的一种具体的细节，它可以有着不同的实现，关系型数据库、NoSQL甚至文件存储都可以用。需要注意的是，这里并不是说数据不重要，而是从本质上来说，架构是对复杂度的治理，而不是对数据的管理。很显然，在大多数的企业架构中，复杂的业务逻辑是治理的重点。
于是，这就催生出了以领域为中心的架构（Domain-centric Architecture）。
在以领域为中心的架构中，领域是架构的中心。这样的好处是，通过分层架构，隔离领域复杂度与技术复杂度，从而实现对两种不同类型的复杂度独立治理，并将重点放在领域上。另外，良好的分层和解耦有利于架构的扩展和稳定，也更易于维护。所以，针对复杂业务场景，或具有较长生命周期的产品，应当考虑这种架构。
当然，以领域为中心的架构只是一种思想，而思想就必然会有不同的实现，DDD是其中的一种实现。在后面的文章里，会介绍六边形架构和洋葱架构是如何实现以领域为中心架构的。
关注公众号【MetaThoughts】，及时获取专栏文章更新通知。
