数据亲和架构的核心目标，是为了解决微服务中的业务逻辑和数据绑定问题。使得业务逻辑在使用数据时，无需更多关注数据的传输和管理细节，确保数据在需要的时候，就能够使用。即使在微服务在异地重启或者多实例重启，数据也能够自动迁移和同步，无需被业务逻辑感知。如此一来，对于微服务来说，实现上与单实例没有太大差别。
在很多场合中，讲解微服务的优势，都要和单体架构比较。在实现业务单元时，微服务架构由于每个单元更加独立，功能实现也更加纯粹；而单体架构因为多个业务混合在一起，耦合性高，相互之间影响度高，需要考虑的因素更加复杂。
单体架构的业务服务单元共处于一个进程中，可以简单的共享同一份数据，数据管理的逻辑也得以共享。但在微服务架构中，业务逻辑分散在多个进程中，可能在不同服务器，甚至跨机房。做为业务逻辑载体的程序，是文件类型，是静态数据，可以采用预部署或者多份冗余方式，减少启动时间。
业务数据本身绝大部分场景下是动态的，甚至是高频的，静态数据的同步手段和延迟无法满足业务需求。另外一种情况，业务数据长期积累，如数据库，会生成大量静态数据，动则几个G级别的，甚至更大，这类数据也是无法轻易迁移的。
数据问题对业务实现至关重要，但在微服务架构下不但没有得到解决，反而让这个问题更加严重。微服务架构通过额外的手段来解决。与此相反，数据亲和架构将数据问题视为核心要解决的问题。
数据亲和架构从业务服务实现角度，重新审视和设计整个架构。