Business logic layer design for Software Design

The Business Logic Layer is undoubtedly part of the system architecture that reflects the core value. Its focus is mainly on the formulation of business rules, the implementation of business processes, and other system designs related to business needs, that is, it is the Domain that the system is dealing) logic is related. In many cases, the business logic layer is also called the domain layer. For example, in the book Patterns of Enterprise Application Architecture, Martin Fowler divides the entire Architecture into three main layers: presentation layer, domain layer, and data source layer. Eric Evans, a pioneer in the field-driven design, divided the business logic layer into the application layer and the domain layer in detail, the solution of domain logic and domain logic is further separated by hierarchy. The business logic layer is critical to the architecture. It is in the middle of the data access layer and the presentation layer, and plays a role in data exchange. Because the layer is a weak coupling structure, the dependency between the layer is downward, and the underlying layer is "ignorant" for the upper layer, changing the design of the upper layer has no impact on the underlying layer of its calls. If the hierarchical design follows the interface-oriented design idea, this downward dependency should also be a weak dependency. Therefore, without changing the interface definition, the ideal layered architecture should be a "drawer" architecture that supports extraction and replacement. Because of this, the design of the business logic layer is critical to an architecture that supports scalability, because it plays two different roles. For the data access layer, it is the caller; for the presentation layer, it is the caller. Dependencies and dependencies are all entangled in the business logic layer. How to decouple dependencies is a task left to designers apart from implementing business logic. Cooperation with field experts The biggest obstacle to designing the business logic layer lies not in technology, but in the analysis and understanding of the business in the field. It is hard to imagine that an architecture designer who is not familiar with the business rules and processes in this field can design a system architecture that meets the customer's needs. It is almost concluded that the design process at the business logic layer must involve the participation of field experts. In projects I used to develop, the fields involved cover many industries, such as electric power, semiconductors, and automobiles. If there is a lack of experts in these fields, the design of software architecture, especially the design of the business logic layer, cannot be discussed. The only exception to this conclusion is that the architect is also an expert in this field. However, it is difficult for us to find such an outstanding talent that is "easy to get, but hard to find. The role of a field expert in a team is usually referred to as Business Consultor (Business consultant). It is responsible for providing consulting related to the field Business and participating in architecture and database design with architects, write Requirement documents and design cases (or User Story ). If you are in the test phase, you should also include writing test cases. Ideally, domain experts should be involved in the entire project development process, not just the demand stage. Field experts can be specialized consultants who have deep knowledge in this field, or customers who are demand providers. In Extreme Programming, customers are introduced into the entire development team as field experts. It emphasizes the on-site customer principle. On-site customers need to participate in various stages of project development, such as planned games, development iterations, and coding tests. As a team of field experts, designers, and developers throughout the development process, the problem of incorrect understanding of requirements can be avoided. Even if the development of the project is inconsistent with the actual needs, it can be corrected in the early stage of the project, which avoids unnecessary project delays and strengthens the control of the project process and cost. As Steve McConnell mentioned in his preparations for building activities, the time for error discovery should be as close as possible to the time for introducing the error. The longer the requirement defect lurks in the system, the more expensive it will be. If you can fully cooperate with field experts in project development, you can avoid such a vicious chain reaction as much as possible. Traditional software development models also focus on cooperation with field experts, but such cooperation is mainly concentrated in the demand analysis stage. For example, the waterfall model emphasizes early planning and demand research. However, this early planning method requires a high level of skill for architects and demand investigators. It emphasizes the accuracy of the requirement documents. Once the analysis is biased or the demand changes, after the project development enters the design stage, it is difficult for developers to make timely corrections because of the lack of communication and cooperation mechanisms with experts in the field. Once these problems spread like cancer in the system and are gradually exposed to developers, they have become an insurmountable Mountain. We need to spend more manpower and material resources to correct these errors, resulting in an increase in development costs by an order of magnitude, or even project delays. Of course, there is also a good choice, that is, to give up the entire project. There are countless examples like this. In fact, most of the reasons for project development are due to problems in business logic analysis. Compared with the waterfall model, the iterative model greatly improves because it allows changes and optimization of system requirements. The entire iteration process is actually a process of cooperation with experts in the field, by presenting the system functions generated by iterations to the customer, the customer can get feedback in a timely manner and solve the problems encountered in iterative demonstrations one by one to ensure that the system evolves to meet the customer's needs. Therefore, the iterative model can often solve the problem of insufficient early planning. It allows re-design, re-code, and re-test when detecting defects and changing requirements. Regardless of the development model used, cooperation with experts in the field will be the key to the success or failure of the project. This is based on the general truth of software development, that is, there is no constant demand in the world. A classic saying goes: "There is no constant demand. The software in the world has been changed more than three times. The owner of the only software that has been changed twice is dead, it's the way to modify the requirement." The cruelty and hardships of software development have been exhausted! So how should we strengthen cooperation with experts in the field? Based on their experience in the IBM SanFrancisco project, James Carey and Brent Carlson proposed the Innocent Questions model, meaning "Improving the quality of communication between experts in the field and technical experts ". In a project team, if we do not have one who can serve as both the chief architect and the candidates for field experts, it is particularly important to strengthen cooperation between field experts and technical experts. After all, as an expert in a field, you may not be familiar with the software design methodology or have the ability to develop object-oriented and architectural design. Similarly, most technical experts are likely to stay focused on the business areas involved in the project. If the field experts and technical experts cannot communicate effectively, the future of the entire project will be in danger. The solutions proposed by Innocent Questions mode include: (1) Select a developer who can be in harmony with others to form a development team; (2) Clearly define roles and permissions; (3) Clearly define the required interaction points; (4) maintain a close team; (5) hire outstanding people. In fact, this has increased from a technical perspective to a management level for the team. Just like playing basketball, even if your team has set up five of the world's top and most talented players, it is still very difficult to win the game if you want to fight independently. Team spirit and clear rights and responsibilities are the guarantee for victory, as are software development. The foundation for cooperation with field experts is to ensure that at least one field expert is always retained in the development team. He can be a system customer, a consultant from a third-party company, and ideally an expert hired by his company. If such a person is lacking in the project, I suggest you hire him, if you don't want to see the project suffer a "Siberian cold wave. Determine the role, tasks, and responsibilities of a domain expert. Each person in the team must specify the roles and responsibilities of the field experts in the entire team. A qualified field expert must have a deep understanding of the business field. He should be a person who can look down on the needs of the entire system and take the overall picture. In the project development process, he is responsible for formulating business rules and processes, communicating with the customer, investigating and discussing requirements, and participating in the design of the system architecture together with the designer. Document editing is a task that must be attended by a domain expert, whether it is a requirement document, design document, or use case writing, a domain expert or comments, or as the author of the writing, at least he should be an important member of the Review Committee. Standardize the terms and technical terms in the business field. Domain experts and technical experts must communicate with each other in a semantic environment without ambiguity. If there are differences in understanding, we must resolve them in a timely manner and establish terminology standards through discussion. It is hard to imagine that people with different languages can cooperate happily. The solution is to join a translator. It builds a semantic bridge between domain experts and technical experts so that they can understand and recognize each other. Another way is to conduct training activities within the team. Especially for developers, they are more or less familiar with some business fields, which is of great help to project development. During the project development in the semiconductor field that I participated in, the team specially invited experts from the semiconductor industry to give a comprehensive introduction and training on the business logic of the production process. Although we spent the training time, developers who have mastered the business rules and procedures can improve the project development progress and reduce development costs. Strengthen communication with customers. Customers can also serve as field experts in the team. The on-site customer principle of extreme programming is the best example. However, the reality is not so perfect. When the customer cannot be asked to become a fixed member of the development team, he should hire or arrange a specialized field expert to strengthen communication with the customer, it is particularly important. The project can receive timely feedback from customers through field experts. The field experts can help you understand the needs of changes, minimizing the possibility of demand errors. Business logic layer mode Application In his book "enterprise application architecture model", Martin Fowler summarized the architecture model of the domain layer (namely the business logic layer). He divided the business logic design into three main models: transaction Script, Domain Model, and Table Module. The Transaction Script Mode regards the business logic as a process, and is a typical process-oriented development mode. You can use the Transaction Script Mode to directly access the database without the data access layer. To effectively manage SQL statements, you can place database access-related behaviors in a dedicated Gateway class. The application of the Transaction Script Mode does not require much object-oriented knowledge. The simple and direct feature is the full value of this mode. Therefore, many projects with relatively simple business logic apply the Transaction Script Mode. The Domain Model mode is a typical embodiment of object-oriented design ideas. It fully considers the complexity and variety of business logic, introduces design patterns such as the Strategy model, and implements scalability of the model by establishing domain objects and abstract interfaces, it also utilizes the inherent characteristics of Object-oriented Thinking, such as inheritance, encapsulation, and polymorphism, to process complex and variable business logic. The only application that restricts this mode is the ing between objects and relational databases. We can introduce the ORM tool or use the Data Mapper mode to map the relationship to the object. Similar to the Domain Model pattern, the Table Module pattern also has the idea of object-oriented design. The only difference is that the object it obtains is not a pure Domain object, but a DataSet object. If you create a simple ing relationship between a relational data table and an object, the Domain Model mode creates a Domain object for each record in the data table, the Table Module mode regards the entire data Table as a complete object. Although the use of the DataSet object will lose the basic features of object-oriented, it has a unique advantage in providing data source support for the presentation layer. Especially on the. Net platform, ADO. NET and Web controls provide a fertile ground for the growth of the Table Module model.