如果考虑到这两个问题都是正确的，与你想要实现的适当背景。
如果你想实现一个仅适用于Android的解决方案，那么Android开发者文档更适合你。如果你想创建一个针对多平台（Android、iOS、桌面）的项目，那么ProAndroidDev的架构更适合你。
另外，在阅读他们的文档时，我希望你记住他们的最终目标和背景。
在Android开发者文档中，数据层由实体和存储库类组成。这些类在Usecase类中是必需的，因此Domain层依赖于数据层。在此架构中，假设您仅为Android构建应用程序，因此不需要为存储库类创建抽象，因为它会增加复杂性。
在ProAndroid dev的文档中，假设您现在正在为Android构建应用程序，稍后您可能会引入其他平台，或者您现在只针对多个平台。在这种情况下，Repository类抽象变得更加重要，因为通过在早期添加它，您可以减少未来的bug/重构。在此文档中，为了实现上述目的，而不是数据层，域层现在包含Usecase、Entity和Repository接口类，数据层包含Repository Impl类。因此，域层不需要任何依赖关系，因此它不应该对其他层有任何依赖关系。
我认为在ProAndroid开发者的博客中，如果他们将包含Repositories的层称为Repository Layer而不是Data Layer，那么这种混淆就可以避免。在Android的博客中，他们将其称为Data layer，因为它包含实际的数据/POJO类和Repository类（负责管理此数据的类）。

我将尝试独立于Android做出回应，因为我根本不是这方面的Maven。从纯粹的设计概述：
需要注意的几点：

• 在任何架构中都没有固定的层数。
• DataLayer不仅仅是关于来自数据库的数据，它可以是来自应用程序外部的任何数据（API.）。你可以称之为Dependency来简化事情，就像Robert Martin在Clean Architecture中所做的那样。
• 总是存在依赖关系，层只是一种抽象和识别事物的方式。我们尽量不太依赖数据，但总是存在依赖关系。但让我们让一些事情变得更容易。

我们在设计中尝试做的是创建范围（层，分类）来分离关注点并添加抽象。有很多架构试图以不同的方式将其放置到位，但目标是相同的：

• 良好的分类/抽象
• Dependency上的小耦合（框架和外部系统：数据库，API...）
• 使系统更改更容易，并限制更改的影响

我同意Ashok的观点，这两个问题在一定程度上是正确的。这取决于你将遵循哪种架构：领域层通常是关于系统的核心，它意味着软件要解决什么功能和什么问题，你在这一层实现独立于外部系统、框架、应用层（终点，如何展示你的程序特性.）这就是为什么我们称之为领域层，一些开发模式或策略，如领域驱动设计，可能适合开发这种层，并给予更多的技术和选择，以成功地实现它正确或更干净。我建议看看它（尝试找到一个好的资源或只是购买埃里克的书，许多人在互联网上解释这个设计不正确）。
所以这一层将有它们的类（域实体，可能是服务.）在第二层DataLayer中被称为什么（我称之为扩展性=外部系统依赖性+框架扩展性）你的域层应该只依赖于来自这一层的接口。域层不应该给予对扩展性实现的兴趣。
表示层在开始使用域层时（可能是通过直接调用，或者通过API，它取决于应用程序），它不应该使它们的视图（UI）依赖于域暴露的类/对象的结构。表示层应该创建自己的类/对象，并转换域暴露的数据。这可以避免域中的更改破坏表示层。

注意事项：在前端与后端分离的设计中，另一个称为应用层的层可能包含向表示层公开域功能的端点。

对不起，这类问题很难简单回答。请不要犹豫，与我联系以获得更多的澄清。