软件架构中有一个鲜为人知的模式，值得更多关注。首次由Rajive Joshi在RTI的2007年白皮书中描述了面向数据的体系结构 ，然后在2017年由维也纳大学的Christian Vorhemus和Erich Schikuta 再次描述。
在面向数据的体系结构DOA中，共用数据库是系统中状态的唯一来源，松散耦合的无状态微服务对这共用数据库进行操作。（banq注：DOA=SOA+微服务，是两者中间体，不同于微服务，DOA共用一个数据库，服务不是SOA的大服务，而是微服务中微小服务，在实践中大量存在这种过度式的架构，从SOA到微服务过渡中间架构）
在面向数据的体系结构（DOA）中，系统仍然围绕小型，松散耦合的服务组件进行组织，就像在SOA微服务中一样。但是DOA在两个关键方面不同于微服务：
- 组件始终是无状态的DOA不需要按照集中管理的全局模式来描述数据或状态层，而是对每个相关组件进行组合和联合统一地数据存储。
- 组件之间的交互被最小化，而有利于通过数据层的交互在我们的交易系统中，接收不同证券价格的组件只是以规范的形式在我们的数据存储中发布价格。系统可以通过查询数据层的价格来消耗这些价格，而不是通过特定的API向特定服务（或一组服务）请求价格。在这里，积分成本是线性的。DOA模式更改意味着最多可能需要更新N个组件，而 它们之间最多需要N 2个连接。
真正亮点是：当高级数据类型由不同的数据提供者填入时，用一张数据表替代一项服务，好处是：如果有多个具有相同常规数据类型的源，下游系统只要查询该表，而不必担心请求来自何处，例如如果交易系统连接到多个市场，每个市场都将它们的客户请求发送到一个RFQ表查询即可。
HN讨论：
大规模数据将使得数据库变成了瓶颈。不过，这绝对不是缺点，因为这意味着您可以将数据库的所有权集中到一个专家团队，该专家团队可以为每个人处理优化，容量规划，分片，多租户，安全性，监视等问题。大多数产品团队不需要也不需要具有该专业知识的人员，因此，如果您有多个产品或服务遇到可伸缩性问题，则与让每个产品或服务独立处理这些问题相比，此方法可能是一种更具成本效益的解决方案。
在某种程度上，这是描述基于事件的SOA系统的一种非常轮回的方式。所描述的许多问题是来自SOA系统的问题，SOA系统正在为SOA系统使用许多常见的反模式。同样，此人描述DOA的方式虽然业务逻辑不是整体的，但是可能最终偶然地紧密耦合。即使使用DOA，如果做错了，也可能导致服务之间的内部状态耦合。相比某些设计不良的SOA系统，这要困难得多，但IMHO的可能性与与事件进行通信的SOA系统大致相同。
我喜欢这种体系结构，但是我担心，如果数据库中存在围绕它们存在大量请求争用一个实体表，那么在足够复杂的系统中，这会导致相当大的复杂性。例如，当彼此天真的两个服务在交互序列中开始锁定表时，它可能最终转换成死锁等。即使您遵循此模式将数据库的区域划分为特定服务或使用者的管理，然后使那些现有的API或消息传递接口彼此交互，这似乎仍然是明智的。这使您一半回到了SOA或微服务。
将服务操作的数据放在同一张表中又有什么意义呢？每个服务一个表，不香吗？您仍然可以将它们全部“联合Join”以进行分析。
这是大约20年前的主要架构设计。这样做有很多优点，一般的挑战是...
- 数据库并没有太多集成方式...
- 数据库可能成为只能垂直扩展的性能瓶颈。
- SQL语言不像应用程序编程语言那么出色
- 编辑：忘记了最大的问题，因为一切都存在于数据库中，因此在实现细节和公共api之间产生任何形式的分离完全取决于纪律。这确实是最大的挑战。
面向数据的体系结构不是一个好主意。SOA的一项重要改进是DDD（领域驱动设计），其中上下文的重要性和边界应包括服务及其数据。
banq注：DDD函数架构才是未来：https://www.jdon.com/53848