java如何使用spring的分层架构，并且仍然遵循面向对象的结构？

Question

我学习了spring及其分层结构（控制器、服务和dao）

@Controller("userController")

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

@Repository("userDAO")

现在我很困惑如何利用良好的OOPS实践（比如this）和这些分层结构来创建一个大项目（现实世界中的业务逻辑比通常提供的示例应用程序更复杂）。我还想使用这些spring事务和框架提供的其他功能。 能否请一些人帮我解决这个问题，或者参考开源项目来澄清我的疑问

Answer 1

简而言之

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

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

• 封装——特定于域模型的业务逻辑应该包含在其中
• 抽象——在抽象中编写通用业务逻辑时，根据服务分组隔离接口
• 继承-在绘制域对象时使用
• 多态性——当您想要更改子模型的业务逻辑时，还需要继承

---

细节

下面我将尽我所能为本次讨论提供一个ERP应用程序的示例。希望ERP是一个足够的大项目来查看业务逻辑的复杂性

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

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

---

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

它包含实际表到类的映射

In an ERP example, this is where you get the models: CustomerOrder, CustomerOrderLine

This also contains the en-capsuled logic of child domain objects and the domain logic of self. For example, the CustomerOrderLine is a child of CustomerOrder. The child cannot exists without the parent. So the parent will have the full control of building the childs within it. ie Business logic encapsulation.. ie: Add CustomerOrderLine, RemoveCustomerOrderLine etc.. And when it comes to self domain logic, ApproveCustomerOrder, RejectCustomerOrder etc..

---

2。数据访问层-存储库

它只包含简单的CRUD到带有SELECT, INSERT, UPDATE and DELETE SQLs的数据库。您可以在Spring中使用repository模式和Spring Data JPA

关键提示：除非您的逻辑是高度数据密集型的，否则不要在此层中编写任何复杂的逻辑。

在这种情况下，您可能需要编写一个或多个函数来执行复杂的查询语句。（最好是在JPQL

In an ERP example, this is the place you write logic for GetCustomerOrders, GetCustomerOrderByCustomer, GetCustomerOrderLines, GetOrderByStatus

In simple terms this layer defines how the application will communicate with the outside entities such as Database.

---

3。服务层

这是您应该放置复杂业务逻辑的地方，它涉及多个未连接（而非子-父）域模型。这些将在Web控制器和Rest API控制器中重用

因此，为了保持一致性并实现安全性，我希望所有的业务逻辑（即使是在域模型中编写的）都被封装在这一层

In the ERP exmple this is the place you write the logic or wrap the logic which is written in Domain Model. For example CreateCustomerOrder, ListCustomerOrder, ApproveCustomerOrderLine, ReleaseCustomerOrder,...

如果这些逻辑应该与其他模型逻辑一起执行，那么这些逻辑也应该在服务层内按顺序调用。例如

关于复杂业务逻辑的杂项示例

If you want to create a Purchase Order for your supplier, when the Customer Order is released.

然后，这可以通过创建一个名为SupplyChainService的服务来实现，该服务使用Spring AOP绑定到CustomerOrderService.ReleaseCustomerOrder。在微服务设计中，这可以通过Supply chain域微服务发布到队列的事件来完成，并被Customer Order域微服务消费

---

4。控制器

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

In the ERP system, this is the place where you will write the controller for your customer order form to enter data and save it to create a new customer order.

This will be the place you will also create a API controller like REST to create the customer order via a mobile application or from a windows client.

感谢SO社区向我展示了我在这个回答中没有涉及OOP原则的领域

编辑

---

当微服务不是太主流时，这是一个答案。虽然它回答了OOP的概念，但也考虑了基于CQRS的设计，因为它在现代基于微服务的体系结构中更为常见。无论采用哪种方式，无论使用何种软件体系结构模式，都可以合并OOP概念

Answer 2

您试图理解两个可以相互操作的不同概念

分层架构

分层架构是该行业的架构风格之一。在这种情况下，我们有单独的层来做特定的逻辑。例如，我们有表示层、业务层和数据服务层。这被称为应用程序的水平切片。还有其他体系结构样式，比如面向服务/基于组件的体系结构，其中应用程序是垂直切片的

假设您有自动预订流程。通常，如果你采用分层架构设计（水平切片），那么我们有不同的层来完成所需的工作。但是，当涉及到垂直切片时，我们会识别应用程序的不同实体，如预订、客户管理、资金管理。我们将实现这些组件，它们相互通信以构建我们的预订应用程序。这里需要记住的一点是，内部组件可以搁置相同的分层架构

面向对象的概念

OOPS概念帮助您以面向对象的方式设计应用程序。一旦确定了架构风格，就必须以易于维护的可扩展方式实现应用程序。因此，它们采用了不同的实现方法。哎哟，真是太棒了。它提出了一些设计原则，帮助您更好地实现应用程序

见SOLID