"Anatomy PetShop" series V: PetShop's business logic layer design

The Business Logic layer (Business Logic Layer) is undoubtedly the part of the system architecture that embodies the core value. Its focus is mainly on the development of business rules, the implementation of business processes and other business requirements related to the system design, that is, it is related to the domain of the system to deal with the logic, many times, we also call the business logic layer as the domain layer. For example, Martin Fowler, in the book Patterns of Enterprise Application architecture, divides the entire architecture into three main layers: the presentation layer, the domain layer, and the data source layer. Eric Evans, the pioneer of domain-driven design, makes a more detailed division of the business Logic layer, divided into application and domain layers, and further separates domain logic from domain logic solutions by layering.

The position of the business logic layer in the architecture is critical, it is in the middle of the data access layer and the presentation layer, and it plays the role of the connecting link in the data exchange. Because the layer is a weakly coupled structure, the dependency between the layers is downward, the bottom layer is "ignorant" to the upper layer, and changing the top design has no effect on the underlying level of the call. If you follow the idea of interface-oriented design in layered design, this downward dependency should also be a weak dependency. Thus, without changing the definition of the interface, the ideal layered architecture should be a "drawer" architecture that supports the removable, replaceable type. Because of this, the design of the business logic layer is particularly critical to support an extensible architecture, because it plays two different roles. It is the caller for the data access layer, but it is the caller for the presentation layer. Dependence and dependency are entangled in the business logic layer, how to realize the decoupling of dependency is the task left to the designer except to realize the business logic.

5.1 Cooperation with field experts

The biggest obstacle of designing business logic layer lies not in technology, but in the analysis and understanding of domain business. It is hard to imagine that an architect who is unfamiliar with the business rules and processes in the field can design a system architecture that meets the needs of the customer. It is almost possible to conclude that the design process of the business logic layer must involve the domain experts. I have been involved in the development of the project, covering the field of electricity, semiconductors, automobiles and many other industries, if the lack of experts in these areas, software architecture design, especially the business logic layer design is impossible to talk about. The only exception to this conclusion is that architects are also experts in the field. However, it is very difficult to find such outstanding talents because the so-called "thousand Army is easy to get, one will be difficult to ask".

The role of field experts in the team is often referred to as business Consultor (business consultant), responsible for providing consulting on the domain business, working with the architect on the design of the architecture and database, composing requirements documents and design use cases (or user stories, Story). If you are in the testing phase, you should also include writing test cases. Ideally, the domain experts should be involved in the development of the entire project, not just the requirements phase.

Field experts can be specialized consultants who have a deeper attainments in the field, or customers who serve as demand providers. In extreme Programming (Extreme programming), customers are introduced to the entire development team as domain experts. It emphasizes the field customer principle. Onsite customers need to participate in all stages of project development, such as planning games, developing iterations, and coding tests. As domain experts and designers and developers form a team, throughout the development process, you can avoid the need to understand the error occurred. Even if the development of the project is not in conformity with the actual requirements, it can be corrected early in the project so as to avoid unnecessary postponement of the project and strengthen the control over the process and cost of the project. As Steve McConnell in the early stages of building an activity: the time to find the error is as close as possible to the time when the error was introduced. The longer the bug in the system lurks, the more expensive it will cost. If you can cooperate fully with the field experts in the project development, we can avoid such a vicious chain reaction with maximum effect.

The traditional software development model also attaches importance to the cooperation with domain experts, but this kind of cooperation mainly concentrates on the requirement analysis stage. The waterfall model, for example, emphasizes early planning and demand research. However, this proactive planning approach is very demanding for architects and demand investigators, emphasizing the accuracy of the requirements document, once the analysis is biased, or if the requirements change, and as the project develops into the design phase, it lacks the mechanism to communicate and collaborate with the domain experts, Developers can not estimate these errors and errors, so it is difficult to make timely corrections. Once these problems spread like a cancer in the system and become exposed to the developers, they have become an insurmountable mountain. We need to consume more human and material resources to be able to correct these errors, which leads to an increase in the number of development costs, and even lead to project delays. Of course, there is a good choice, is to abandon the whole project. Such examples abound, in fact, the reason for the "Waterloo" of project development is mostly due to problems in business logic analysis.

The iterative model has greatly improved compared with the waterfall model, because it allows for changes and optimizes system requirements, the entire iterative process is actually a collaborative process with domain experts, by demonstrating the system functionality generated by the iteration to the customer, to get feedback in time, and to solve the problems that arise in an iterative demo, Ensure that the system evolves in a way that meets customer needs. Thus, an iterative model can often solve the problem of insufficient early planning, which allows the redesign, recoding, and testing of changes in requirements when a defect is found.

Regardless of the development model, cooperation with field experts will be the key to success or failure of the project. This is based on the universal truth of a software development that there is no constant demand in the world. A classic quote is: "There is no constant demand, the world's software has been changed more than 3 times, the only one changed only two software owners have died, die in the road to modify demand." "A word to do the software development of cruelty and hardship!"

So how should we strengthen cooperation with experts in the field? Based on their experience with the IBM SanFrancisco Project, James Carey and Brent Carlson the innocent questions model, meaning "improving the quality of communication between field experts and technical experts". In a project team, if we don't have a candidate who can be both a chief architect and a domain expert, it is particularly important to strengthen the collaboration of field experts and technical experts. After all, as a field expert, you may not be familiar with software design methodologies or the ability to target object-oriented development and architectural design, and most technical experts are likely to have only a smattering of business areas involved in the project. If field experts and technical experts fail to communicate effectively, the future of the entire project is at stake.