How to correctly divide business logic and non-business logic in hierarchical architecture in back-end development?

Back-end hierarchical architecture: cleverly divide business logic and non-business logic

In back-end development, a layered architecture (for example, Controller, Service, and DAO layers) is crucial. Although the hierarchy principle is clear, in practice, especially the boundaries between the Service layer and the DAO layer, as well as the logical division after the introduction of the Manager layer, are often confusing. This article will explore how to effectively distinguish between business logic and non-business logic.

Definition between business logic and non-business logic

Business logic directly relates to business needs, which users can perceive; while non-business logic is an underlying operation and has nothing to do with business processes, such as database operation details or password encryption.

Here are some examples of non-business logic:

1. Database operation details: UserManager.delete() and DepartmentManager.delete() may delete data in association tables (such as userdeptmodel ) at the same time. This is non-business logic because it only involves database operations, not business processes themselves. Without the Manager layer, the DAO layer can also handle such operations, as long as it has nothing to do with the business.

    class UserManager:
        def delete(self):
            userdao.delete()
            userdeptdao.delete()
   
    class DepartmentManager:
        def delete(self):
            departmentdao.delete()
            userdeptdao.delete()

2. Password encryption: Users do not need to know the details of password storage, and the salt operation can be placed in the DAO or Manager layer.

    class UserDao:
        def make_password(self, passwd):
            return salt(passwd) # Assume that the salt function is used to add salt to the password def save(self):
            passwd = self.make_password(passwd)
            self.passwd = passwd
            super().save() #Suppose super().save() is a database save method

3. DAO layer method naming: Whether a method name like get_super_user is suitable depends on whether it involves business logic. If super is not business-related, it can be used; otherwise, it should be handled at the Service layer.

4. HTTP request encapsulation: The backend-dependent encapsulation can be placed in the DAO layer instead of the Service layer.

Implement functions similar to Django filter in Python

In Django/Flask, data filtering is relatively easy. However, in Python's three-layer architecture, it is necessary to consider how to process request parameters in the DAO layer. If there is no dependency injection framework like Spring, the parameters need to be passed manually. In Java, ORM frameworks such as Hibernate provide powerful data filtering and query functions.

Data Entities and Hierarchical Architecture

Data entities are used for data persistence. In a three-layer architecture, the Controller, Service and DAO layers do not strictly correspond to one by one. The Service layer may call multiple DAOs to complete a business operation, and a DAO may also be called by multiple Services.

In short, correctly distinguishing business logic from non-business logic is the key to back-end development, and a reasonable hierarchical architecture can improve code readability and maintainability.

The above is the detailed content of How to correctly divide business logic and non-business logic in hierarchical architecture in back-end development?. For more information, please follow other related articles on the PHP Chinese website!