Service Granularity Design Principles and service combinations-discuss the crux of application software (2)

Abstract: For enterprise application architecture and Enterprise Technical Architecture, refer to: Top 10 proposition programming rules for eliminating human wolf software in sequence

SOA, SOA, SOA!

Many enterprises are currently conducting SOA-based application governance. The key here is the service and architecture. The architecture has been introduced in the previous <Architecture Overview>, this article focuses on service Granularity Design Principles and service combinations.

The main problem in the current application field is how to control the service granularity and how to combine and use the service?

First, let's talk about the service granularity, how to divide the service, and how to grasp the granularity. This is the key to the system. Currently, there are no standards or guiding principles in this field, leading to system chaos and rigidity, it is also the main crux of the current application software. If this problem is solved well, many things can be solved.

At present, the biggest problem with various application systems is that the backend services are actually determined based on functional requirements (those systems that are both frontend and backend and do not have clear service concepts are not covered in the discussion ), all functional-oriented designs are vulgar designs. Under the influence of such functional-oriented service ideas, the division of service granularity will never be clear, and there is no abstraction based on the nature of the business, it is a specific and easy-to-change function. In this case, the discussion about service granularity is meaningless. In fact, it is only necessary to compile programs around the function.

The division and granularity of services should be based on the Architecture (see). This is the essence of SOA, and services should be dividedService ComponentsAndBasic Service ComponentsThis is the key to service design!

Service ComponentsThe implemented function is similar to a function-oriented service, but the details are completely different. Unlike traditional services that directly manipulate data and process business logic, it does not directly deal with the data layer, it does not involve specific business logic. It calls basic service components in combination to implement a specific business function.

Basic Service ComponentsDo not target features, that is, it does not care about the specific business function calling it. It is oriented to the core basic logic of the business field and is responsible for interacting with the business object and the data layer, therefore, data in this field is encapsulated. Its features are stable and closely related to the data layer. Together with the data layer, it forms the core and key of application system stability, other parts, including service components and UIS, are non-critical and can be replaced at any time.

Design Principles of service component Granularity

After dividing services into service components and basic service components, we can talk about the granularity. First, the granularity of service components is not important. You can divide them according to functional requirements; the granularity of basic service components is the focus of the design. In this case, the design of basic service components is easily defined without the limitations of functions. High Cohesion and low coupling are macro guiding principles, but it is difficult to grasp, so the following basic principles are given:

1) principles of independence and integrity.

To ensure the independence and integrity of a basic service component business concept, this is the most critical principle of the basic service component design. A basic service component completes a complete and independent matter in the business field, it can be shared and used by multiple service components. It does a lot of things, just right.

2) single responsibility principle.

Basic service components have a single responsibility. They only do one thing, do their jobs well, and do not do anything else. Only by doing a single responsibility can the sharing capability and Stability of basic services be improved.

3) atomicity principle.

Basic service components should be non-severable. That is to say, if a basic service component is split, the two parts are never used independently and must be used together, this is the atomicity of basic service components. Otherwise, if a basic service component can be split into two or more components, and they can be used independently, it indicates that this component is not a single function and does not meet the atomicity principle. It must be further split.

4) data relevance principle.

Basic service components are encapsulation of basic business logic and data. They usually interact with the data layer. components that do not need to interact with the data layer can be included in the public function layer, it is not managed as a service component, such as account validity verification and interest calculation module.

5) Principles of interoperability.

Basic service components allow mutual calls and can use shared public library functions.

By grasping the above principles, we can reasonably determine the granularity of basic service components.

 

Architecture of Enterprise Application Systems

Service portfolio

Service composition is a broader topic, involving all aspects of the architecture. It is one-sided to discuss a specific layer separately, from the figure above, we can clearly see that a service combination may occur at three levels:

1) UI Layer-rich

A complex user interface may be associated with multiple background services, file services, and message services, and may start or participate in a business process. This is the most flexible and colorful Service combination.

2) middleware-flexible

Centralized service access on the middleware usually involves simple forwarding of service requests. A service combination is implemented by a process platform or service composition platform, they are typically represented by a visualized process organization or service process scripting language.

This layer is a combination of services based on business processes or processes. It is a key design for system implementation and business flexibility.

3) backend service layer-delicate

Service components are actually process combinations of basic service components and functional-oriented basic encapsulation. Although we emphasize the importance of basic service components, service components are actually the services used by various systems, in other words, from the perspective of application systems, service components are the only visible service, and basic service components are isolated and hidden by service components, service components are the most effective combination of basic service components to achieve system functions.

The Service combination at this layer is delicate and relatively stable. Although it is not as stable as the basic service, it is still relatively stable relative to the combination of the business process and UI Layer.

See http://blog.csdn.net/xabcdjon/article/details/6876058

Http://blog.csdn.net/xabcdjon/article/details/6707050