Hello, I'm Master Tang~
Application architecture design typically includes the following steps:
- Translate business requirements into IT systems and identify core application services based on business architecture.
- Delineate the application structure and design the relationship between the application structure and business processes and data.
- Design the interaction and integration relationships between application structures.
In this article, we are going to share about application services, application architecture design design.
application service design
The concept of application services
An application service is an encapsulation of a closely related business object or set of business objects and their operations.
An application service should clearly define its scope of responsibility and group related business functions and objects together to avoid exposing internal details. It needs to integrate functions and data that change for the same reason, while separating parts that change for different reasons. This design approach ensures that the service is cohesive and flexible.
The concept of application services stems from the rise of SOA and microservices architectures, which can improve the maintainability, scalability, and flexibility of a system by splitting system functions into multiple independent services.
How are application services divided?
Application services play a crucial role in the application architecture, which "packages" the core functions of the system and provides them to external business processes, which can be regarded as the external "facade" of the SaaS system.
Users or other systems realize specific business functions by invoking application services. So, how do you design application services?
1. Align business capabilities and design services with moderate granularity and single responsibility to avoid cross-service calls.
When designing the granularity of application services, you can refer to the concept of "bounded context" in domain-driven design (DDD). Business objects are similar to the aggregation root in the bounding context and are the core of the application service.
Typically, each business capability corresponds to one or more independent application services, while each application service also supports a specific business capability. As shown in the figure.
If an application service supports too many business capabilities, it needs to be assessed whether too many business objects are associated within it. In this case, consider grouping multiple business objects so that the application service can be split into smaller, more focused services.
2, around the business object, to provide specific business functions, with a clear business meaning, can not contain irrelevant functions.
From an external perspective, it appears that application services usually come with clear business implications, generally operate around a particular business object or set of closely related business objects business objects, and should not contain unrelated business functions.
For example, a "mall transaction service" focuses on functions such as order confirmation, order placement and payment, and should not handle other operations such as user authentication and product recommendation.
3、Services can be registered, monitored and measured
Public APIs for application services should be registered with the API management platform to form a list of services for consumers to subscribe to invoke.
When an application service provides services to the outside world, it should be able to monitor its operation status and support start/stop operations. At the same time, the service should be measurable, including the number of subscriptions, the number of invocations, response time and other indicators.
The Value of Service Oriented Architecture
The greatest value of a service-oriented architecture is its agility and flexibility.
Agility is reflected in the fact that services can be quickly adapted and evolve independently.
Flexibility, on the other hand, is reflected in the fact that each service has clear business boundaries, strong functional cohesion, and the ability to manage the lifecycle separately. Specifically:
- Lightweight application: Adopting lightweight application based on service design, each service is independently developed, deployed and operated, and can be delivered independently with a small scope of influence to enhance the delivery efficiency.
- Service reuse and flexible orchestration: Through service reuse and flexible orchestration, it can quickly respond to business changes and support complex business processes.
- High local scalability: After the system is split into independent services, it is easy to expand horizontally, only the necessary parts need to be expanded, lower cost and better results.
Example: Application Service Segmentation for Order Fulfillment Capability
As shown in the figure, order fulfillment capability is the L2 business capability in the business capability map of a retail enterprise. Order fulfillment capability can be subdivided into several end-level business capabilities: ToC fulfillment service, order dispatch, order management, picking management, shipment management and fulfillment reversal.
Based on these end-level business capabilities, we can design the appropriate application services.
Application Architecture Design
The application structure describes the hierarchical structure and organizational relationships within the application services, which determines the degree of modularity of the system and the subsequent difficulty of development and maintenance.
Levels of abstraction of the application structure
In application architecture design, we usually abstract the system into different levels. For example, the system is divided into system level, application level, module level, and code level.
This division of abstraction levels helps us deal with complexity at different levels and ensures that the system structure is clear and easy to maintain. As shown in the figure:
- System level:The focus is on the overall layout and governance of the systems, such as the relationship between the systems and how they work together.
- Application level:Focus on the overall architecture of each application, including how the application interacts with other applications and the role of each application in the overall system.
- Module level:Further refinement of the internal of the application, it involves the modular design of the code, the management of data and state, and so on. Through reasonable module division, the maintainability and reusability of the code can be improved and duplication of efforts can be reduced.
- Code Level:The concern is with the structure and implementation of the code itself. This level of design has a direct impact on the quality and implementation details of the code.
Levels of abstraction exist primarily to help us better manage the complexity of the system.
1. Decomposition complexity
If all the details are mixed together, the whole system will become difficult to understand, maintain and extend. By setting different levels of abstraction, we can break down the complexity of the system to various levels, each of which only needs to focus on specific functions and responsibilities.
This layered approach allows developers to focus on one part of the system without having to pay too much attention to the details of other parts, thus greatly simplifying the system design and development process.
2. Clear boundaries for teamwork
In large projects, there are usually multiple teams developing in parallel. If the system does not have clear boundaries, conflicts and duplication of effort can easily arise between teams.
With clear abstraction levels, different teams can focus on different levels or modules of the system without interfering with each other.
3、Strong scalability
As business requirements change, systems often need to be constantly extended and upgraded. If the architectural design of the system does not have a reasonable level of abstraction, expansion and upgrading will become extremely difficult and may even trigger a complete reorganization of the system.
Whereas in systems with levels of abstraction, changes often only need to be focused on a specific level without affecting the entire system. For example, if a business transformation only affects the module level, we can replace or add a module to meet new business requirements without changing the overall system architecture.
How is the application structure divided?
In the previous article, we mentioned the design methodology of application services, so how can application services be translated into code structures through a step-by-step process?
The application service will be implemented by a series of application structures. As shown in the figure.
Based on the application service segmentation scheme, we can further refine the application structure to better organize and manage system functions.
This process involves multiple levels of design methodology:
- The delineation of systems and subsystems should be aligned with the granularity of business domains and business subdomains. This helps us to better map business requirements to technical implementations.
- One or more related application services may be combined into a single independently deployable application unit.
- Application units can be further layered internally. For example, with reference to the domain-driven design (DDD) layering approach, it can be categorized into a user interface layer, an application layer, a domain layer, and an infrastructure layer.
- Each level of the application unit can be subdivided into multiple modules, each of which contains multiple code units.
In the above design approach, an application service can be deployed individually or a combination of multiple application services can be deployed together.
So what are the specific principles for dividing the application units? The principles for dividing the application can be found below:
1. Principles of business division
The key thing is to refer to the delineation boundaries of the application services. If you need to increase the granularity of the application, you can refer to the division of business domains and business subdomains.
Integrate the functions and data of the same business change factors to improve system cohesion. At the same time, separate the functions and data of different business change factors to reduce system coupling.
2. Principles of technical division
In the early stages of the business, try to start with a single application and avoid dividing application units too early to minimize distributed database transactions and data inconsistencies.
Application units can be further layered within the application unit to avoid circular or bidirectional dependencies between applications, and always maintain unidirectional dependencies between different tiers; higher tiers can depend on lower tiers, and the same tiers should not depend on each other.
Consider splitting the application only when there are real technical pain points, such as scale, performance, and security issues. If not splitting will seriously affect business stability, it should be split. Don't split for the sake of splitting, because each split will increase system complexity.
Example: Application structure division for order fulfillment
As shown in the figure, the application structure of order fulfillment is divided.
The application layer defines the application functions of the software, which is responsible for receiving user requests, coordinating the domain layer capabilities to perform the tasks, and returning the results to the user, the core modules include:
- C-suite fulfillment services
- Estimated Delivery Time: Provides consumers with the estimated processing time and delivery timeframe of the order, which is usually calculated based on a variety of factors such as order processing time, delivery situation, delivery distance, and so on.
- Real-time Order Status Inquiry: Allows consumers to view the stage of their order in real-time. This includes statuses such as order pending, picking, packing, shipped, delivered, etc.
- Distribution track tracking: Provides complete path tracking of the order from outbound to final delivery, consumers can view the current location of the order and past delivery nodes to understand the delivery progress.
- Delivery Information Changes: Consumers may need to change delivery information, such as address or delivery time, before the order has been finalized.
- Delivery Fee Breakdown: Displays a detailed breakdown of the consumer's order delivery fee, including delivery fee, packaging fee, service fee, etc.
- Confirmation of receipt: Consumers can confirm receipt of goods through the system, which is the last step to complete the order process.
- B-side management module:
- Order Dispatch: Receive orders from the sales platform and automatically assign them to the corresponding stores/warehouses according to the established rules.
- Order Management: Comprehensively manage the life cycle of orders, including order confirmation, processing, status tracking, modification and cancellation and other management operations.
- Picking Management: Manages picking operations within the warehouse to ensure that items are accurately and correctly picked from the shelves, packed and shipped.
- Shipping Management: Comprehensively manage the lifecycle of a shipping order, matching the appropriate shipping method based on the address of the order, the size and weight of the product, and the fulfillment method chosen by the customer, and tracking the shipping process.
- Reverse Fulfillment: The Reverse Fulfillment module handles return requests and manages the return refunds and exchanges process when customers are dissatisfied or need to return or exchange merchandise.
The domain layer is the core of business logic, focusing on representing business concepts, business state flow and business rules, and precipitating reusable service capabilities, modules include:
- Fulfillment Service Representation: Responsible for providing customers with clear information on fulfillment services. Includes estimated delivery times, costing, service options (e.g., timed, next day, etc.), and fulfillment accessibility requirements.
- Order Fulfillment Scheduling: Provides the core capability of order fulfillment scheduling to ensure that orders are processed and fulfilled efficiently. It involves all scheduling and processing of orders from receipt to final preparation for distribution, including order splitting, allocation, picking, packing, and shipping.
Dependencies of the order fulfillment system with other systems:
- Commodity management system: the commodity information provided, including price, specification, description, classification, SKU and so on.
- Centralized Inventory System: Access to the Centralized Inventory System (CIS) is required to confirm the physical inventory status of the item(s) ordered, including the quantity and location of the inventory.
- Delivery System: Once the merchandise is packaged, the delivery system will be relied upon to handle the actual delivery of the merchandise, including delivery scheduling, tracking, and status updates. The delivery status and time information provided by the delivery system is critical for updating the order status in the order fulfillment system.
- Basic data system: Provides basic data such as organizational information, user authority information, service provider information, etc. These standardized data ensure the consistency of data across systems
- Data Analysis System: The order fulfillment system will generate a large amount of data, including order data, fulfillment process data, delivery time data, etc., which needs to be transferred to the data analysis system. Based on the collected data, the data analysis system provides analysis and insights to help optimize the order fulfillment process, improve customer satisfaction, and provide predictive analysis to assist inventory management and demand forecasting.
This article has been featured on, my tech site: Inside there are, algorithm Leetcode detailed explanation, interviews eight stock text, BAT interview questions, resume templates, architecture design, and other experience sharing.