我需要对 Java EE 环境中的三个软件架构层（如下所列）进行深入的解释，我从多个上下文中获取了这些信息。简而言之，这就是我的收获：
浏览多篇文章后，我对区别在服务层和持久性层之间的位置感到困惑——它们可能重叠还是彼此的同义词？我从来没有听到他们在相同的背景下被提及。
所有这些层总是被使用/容易区分吗？
谢谢。
【问题讨论】：
标签： java service architecture repository persistence
服务层封装了应用程序的业务逻辑和计算。 Service 一词用于强调使用Service-oriented design principles 建模的业务逻辑层可以被不同的消费者使用，例如，Web 表示层、API 集成层、远程移动客户端、其他服务等等。服务的示例可以是 PayrollService、DiscountService、OrderService 等。这使得业务逻辑只需编写一次，就可以在不同的技术、位置和应用程序的多个地方使用。
持久层负责向服务层提供数据访问操作。为了遵循松耦合的原则，服务层不应该担心数据的存储方式和存储位置——只要它可以在需要时访问所需的数据。服务层应该简单地将所需的业务逻辑应用于数据，以便数据访问代码与业务逻辑代码分开（在任何严肃的企业应用程序中）。
Repository 是一种常用于实现持久层的设计模式。除其他外，它允许将应用程序数据建模和管理为领域模型（技术团队成员和业务用户共享业务领域共同理解的一种方式）。这允许使用Domain-driven design，方法是确保技术用户和非技术用户共享一个共同的术语，并且技术工件尽可能地模仿他们的真实世界对应物。存储库模式也很有用，因为它允许服务层通过一致的接口访问所有（或至少大部分）数据源（大多数提供基于存储库的持久层的框架在所有存储库上提供基本的 CRUD 方法）。存储库的示例可以是 OrderRepository、PersonRepository、DepartmentRepository 等。Martin Fowler 的网站有一个 excellent overview of the repository pattern。
也就是说，存储库并不是设计和实现持久层的唯一方式——它也可以通过其他方式实现，最简单的是使用本地数据访问技术，如 JDBC、ODBC、ADO.NET、等等
现在，回答这个问题，Service 和 Persistence 层应该在适当架构的软件系统中分开，以提供业务逻辑和数据访问组件之间的松散耦合系统（如果您同意业务逻辑和数据访问是两个独立的问题）。请参阅SOLID principle，了解将单个应用程序关注点封装为单独组件的入门知识。这两个层之间的任何重叠都是不好的，因为它会导致硬耦合、可能的代码重复、分散的错误、代码不灵活等。
Repository 是一种设计模式，也是实现持久层的可能方式之一，尽管还有其他方式来实现持久层。以下视觉描述可能会有所帮助：
------------------------------- -------------------------------
| W e b l a y e r | | A P I l a y e r |
------------------------------- -------------------------------
-------------------------------------------------------------------------------
| S e r v i c e l a y e r |
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
| P e r s i s t e n c e l a y e r |
-------------------------------------------------------------------------------
---------------------------
/ /
---------------------------
/ /
---------------------------
/ D a t a S t o r e s /
---------------------------
【讨论】：