简而言之
当分层架构变得庞大和复杂时，分层架构将简化其代码的可维护性和一致性。
要记住的事实是在执行实施之前要进行适当的软件设计。
- 封装-特定于域模型的业务逻辑应该放在其中。
- 抽象-根据服务分组隔离接口，同时在抽象中编写公共业务逻辑。
- 继承-在起草域对象时使用
- 多态-与继承一起，当您想更改子模型的业务逻辑时。
详细
下面，我尽力为该讨论提供一个ERP应用程序的示例。希望ERP是一个足够 大的项目， 可以查看业务逻辑的复杂性。
以下描述适用于需要在Spring（或任何其他框架）中理解和利用分层项目结构的任何开发人员。
但是请注意，这些不是要遵循的规则，而是要利用的最佳实践。 :)
1.数据访问层-模型/域对象
这包含实际表到类的映射。
在ERP为例，这是你在哪里得到的模型：
CustomerOrder，CustomerOrderLine这也包含子域对象的封装逻辑和自身的域逻辑。例如，
CustomerOrderLine是的子项CustomerOrder。没有父母，孩子就不能存在。因此，父母将完全控制在其中建立孩子的能力。即
业务逻辑封装。 。即：AddCustomerOrderLine，RemoveCustomerOrderLine等等。而当谈到自己的域逻辑，ApproveCustomerOrder，RejectCustomerOrder等。
2.数据访问层-存储库
它仅包含使用到数据库的简单CRUD
SELECT, INSERT, UPDATE and DELETESQLs。您可以在Spring和一起使用存储库模式
Spring Data JPA。
重点说明：除非您的逻辑是高度数据密集型的，否则请勿在此层中编写任何复杂的逻辑
在这种情况下，您可能必须编写一个或多个函数来执行复杂的查询语句。（最好在中
JPQL）
在ERP为例，这是你写的逻辑的地方
GetCustomerOrders，GetCustomerOrderByCustomer，GetCustomerOrderLines，GetOrderByStatus简单来说，该层定义了应用程序如何与外部实体（例如数据库）进行通信。
3.服务层
在 这里应放置涉及多个未连接（非父级）域模型的复杂业务逻辑 。这些将在Web控制器和Rest API控制器中重用。
因此，为了保持一致性并 实现安全性 ，即使将域模型中编写的所有业务逻辑都包裹在这一层中，我也希望使用所有业务逻辑。
在ERP示例中，这是您编写逻辑或包装在域模型中编写的逻辑的地方。例如
CreateCustomerOrder，ListCustomerOrder，ApproveCustomerOrderLine，ReleaseCustomerOrder，…
如果这些逻辑应与其他模型逻辑一起执行，则也应在服务层内依次调用这些逻辑。 例如。
复杂业务逻辑的其他示例
如果要
Purchase Order为您的供应商创建，Customer Order则发布时。
然后，可以通过创建一个
SupplyChainService使用Spring
AOP绑定到的服务来完成
CustomerOrderService.ReleaseCustomerOrder。在微服务设计中，这可以通过
Supplychain域微服务发布到队列中的事件来完成，并由
Customer Order域微服务使用
4.控制器
控制器可以分为两类，即：Web控制器和REST控制器。在此层中不应实现任何业务逻辑，因为在Web和API级别中都可以调用相同的逻辑。
在ERP系统中，您将在此处编写用于客户订单表单的控制器，以输入数据并保存以创建新的客户订单。
在这里，您还将创建一个REST之类的API控制器，以通过移动应用程序或Windows客户端创建客户订单。
感谢SO社区向我展示了我在此答案中未涉及的OOP原则的领域
编辑
当微服务不是太主流时，这就是答案。
尽管它回答了OOP概念，但也要研究基于CQRS的设计，因为它在现代基于微服务的体系结构中更为常见。无论哪种方式，无论使用哪种软件架构模式，都可以合并OOP概念。
