@Controller("userController")

@service("userService")
@Transactional(     propagation = Propagation.REQUIRED,     isolation = Isolation.DEFAULT,      readOnly = true)

@Repository("userDAO")

简而言之

当分层架构变得庞大和复杂时，分层架构将简化其代码的可维护性和一致性。

要记住的事实是在执行实施之前要进行适当的软件设计。

• 封装-特定于域模型的业务逻辑应该放在其中。
• 抽象-根据服务分组隔离接口，同时在抽象中编写公共业务逻辑。
• 继承-在起草域对象时使用
• 多态-与继承一起，当您想更改子模型的业务逻辑时。

---

详细

下面，我尽力为该讨论提供一个ERP应用程序的示例。希望ERP是一个足够 大的项目， 可以查看业务逻辑的复杂性。

以下描述适用于需要在Spring（或任何其他框架）中理解和利用分层项目结构的任何开发人员。

但是请注意，这些不是要遵循的规则，而是要利用的最佳实践。 :)

---

1.数据访问层-模型/域对象

这包含实际表到类的映射。

在ERP为例，这是你在哪里得到的模型：CustomerOrder，CustomerOrderLine

这也包含子域对象的封装逻辑和自身的域逻辑。例如，CustomerOrderLine是的子项CustomerOrder。没有父母，孩子就不能存在。因此，父母将完全控制在其中建立孩子的能力。即
业务逻辑封装。 。即：Add CustomerOrderLine，RemoveCustomerOrderLine等等。而当谈到自己的域逻辑，
ApproveCustomerOrder，RejectCustomerOrder等。

---

2.数据访问层-存储库

它仅包含使用到数据库的简单CRUD SELECT, INSERT, UPDATE and DELETE SQLs。您可以在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。在微服务设计中，这可以通过Supply chain域微服务发布到队列中的事件来完成，并由Customer Order域微服务使用

---

4.控制器

控制器可以分为两类，即：Web控制器和REST控制器。在此层中不应实现任何业务逻辑，因为在Web和API级别中都可以调用相同的逻辑。

在ERP系统中，您将在此处编写用于客户订单表单的控制器，以输入数据并保存以创建新的客户订单。

在这里，您还将创建一个REST之类的API控制器，以通过移动应用程序或Windows客户端创建客户订单。

感谢SO社区向我展示了我在此答案中未涉及的OOP原则的领域

编辑

---

当微服务不是太主流时，这就是答案。
尽管它回答了OOP概念，但也要研究基于CQRS的设计，因为它在现代基于微服务的体系结构中更为常见。无论哪种方式，无论使用哪种软件架构模式，都可以合并OOP概念。