How to distinguish between business logic and non-business logic in back-end development and perform reasonable layered design?

Back-end hierarchical architecture: clear boundaries between business logic and non-business logic

In back-end development, the common three-tier architectures of controller, service and dao are not always clear enough. This article discusses how to effectively distinguish between business logic and non-business logic in the service and dao layers, and even after introducing the manager layer, so as to build a more reasonable layered design.

Definition between business logic and non-business logic

Business logic directly relates business requirements, while not business logic is responsible for underlying operations, such as data access, data verification, etc. Blurred boundaries between the two often lead to confusion in code.

1. Encapsulation of data operations: For example, UserManager.delete() and DepartmentManager.delete() may handle the associated deletion of UserDeptModel at the same time. This is non-business logic because it focuses on data consistency rather than the business process itself. Code example:

    class UserManager:
        def delete(self, user_id):
            self.user_dao.delete(user_id)
            self.user_dept_dao.delete_by_user_id(user_id)
   
    class DepartmentManager:
        def delete(self, dept_id):
            self.dept_dao.delete(dept_id)
            self.user_dept_dao.delete_by_dept_id(dept_id)

2. Data security processing: password salting and other operations are usually performed at dao or manager layer, because this is a data protection mechanism, not business logic. Code example (Python with hypothetical salt function):

    class UserDao:
        def save(self, user):
            user.password = self.salt(user.password)
            # ... save user to database ...
   
        def salt(self, password):
            # ... password salting logic ...
            return salted_password

3. DAO layer method naming specification: DAO layer method names should avoid including business meanings. For example, get_super_user() is not as clear as get_user_by_type("super") .

4. External service call encapsulation: If the backend depends on external services, these calls should be encapsulated at the DAO layer, not the service layer, because this is data access, not business logic.

Simulate Django filter function

In Python, if there is no dependency injection framework, mocking Django filter requires processing request parameters at the DAO layer and passing them layer by layer. Java's Spring framework simplifies this process.

Data entity and hierarchy relationship

Controller, service and dao do not correspond one by one. Their responsibilities are as follows:

1. Controller: System entry, receive and process requests, keeping it lightweight.
2. Service: The core business logic processing layer is relatively complex.
3. DAO: The data access layer is only responsible for data interaction and does not include business logic.

For example, "Create User" business: The Service layer performs "check whether the user name is duplicated" and "create user"; the DAO layer provides "query users based on user name" and "save users" methods.

By clearly distinguishing business logic from non-business logic and following a reasonable layered design, the maintainability and scalability of the code can be improved.

The above is the detailed content of How to distinguish between business logic and non-business logic in back-end development and perform reasonable layered design?. For more information, please follow other related articles on the PHP Chinese website!