Summary: In the previous article, How can Business Teams Unify Architectural Design Styles? , discusses a design specification for a business architecture to achieve these goals: constraining technical details with standards; Pushing standards with technical tools rather than documentation; Constantly reinventing rather than building new wheels; Focus on business modeling. But the whole thing is abstract. This article will summarize the team’s recent architectural evolution efforts and explain this concept in more technical detail as a practice for unifying the business design style. In this paper, the design specification and the construction method based on the specification are described in detail, and many questions of the previous article are answered at the end.

The author wood source sink | | ali technology to the public

A background

In my last post, How can Business Teams Unify Architectural Design Styles? , discusses a design specification for a business architecture to achieve these goals: constraining technical details with standards; Pushing standards with technical tools rather than documentation; Constantly reinventing rather than building new wheels; Focus on business modeling. But the whole thing is abstract. This article will summarize the team’s recent architectural evolution efforts and explain this concept in more technical detail as a practice for unifying the business design style. In this paper, the design specification and the construction method based on the specification are described in detail, and many questions of the previous article are answered at the end.

2 the overview

The figure above illustrates the layers of a standard framework, using an e-commerce product as an example. First, a brief overview of the concept will be given. The next chapter will explain the design protocol and construction method of each layer in detail:

• Product Pattern layer

Describe the complete list of features in the product contract; Identify the application scenarios of product features as signatories; A contract group is used to describe an independent and complete functional domain, and the set of the group is the scope and boundary of product functions. By assembling contract groups, you can quickly build commercial products.

• Business Model layer

In order to reduce the differences in modeling styles among students with different technologies, we made many agreements on the application scenarios of business models, connecting basic modules such as warehouse management/business process/business components. Everyone was more focused on how the business was expressed in the model and much less focused on implementation details. Business models can be built quickly based on domain analysis.

• Business process layer

A set of standard business process framework is used to describe the complete execution process of business model. Business component is a set of highly cohesive business function set. Based on component configuration, the information of business model is adapted to standard parameters, and specific functions are performed by infrastructure. The process engine is responsible for creating and managing process instances, receiving instructions to trigger the execution of component actions, and implementing branch management requirements such as state advancement/conditional jumps and exception handling. Business processes can be quickly constructed by abstracting and precipitating business components/infrastructure.

• Data view layer

A standard data flow mechanism is used to meet the customization requirements of the view layer: Data flow subscribers are used to collect data, physical sources include blockchain cross-chain data/business DB data/file system data/offline task data, etc. Data flow consumer is used to process raw data, generate display layer data/data to be checked/data indicators and so on. Subscriber ensures stable data source and low-cost fast access, while consumer is left to technical students to customize business logic. Data views can be built quickly without interfering with domain modeling.

Detailed explanation of the rules

1 Product Model

Product contract

1) specification

The product contract describes the complete business model from a global perspective, including: the target customer of the service, the business area of dependence, the service output, and so on

The content of the product contract is a static description document that requires a list of signatory identities to define usage scenarios

Example 2)

Taking e-commerce products as an example, the product contract signed separately by the merchant is regarded as the merchant contract, which describes the requirements of the product on the shelf. Product contracts signed by merchants, platforms and buyers are applicable to the scenario of trading orders.

3) set up

• Add/modify low code: based on business requirements, design product template in product center, define contract grouping and specific content
• Usage: access code, one-time: write model classes corresponding to product contract and signing identity in the business system, complete the docking with the product center, including the creation/invalidation of contract, contract query based on signing identity, etc

Contracts are grouped

1) specification

1. Contract groupings describe, from a local perspective, the functions and dependent configuration information provided by a highly cohesive business domain, including business models, business services, business processes, business components, and so on
2. Multiple contract groups together form a product contract for a deliverable business

Example 2)

Under the e-commerce product contract, the product group describes the process and configuration of the product listing, the order group constrains the process and service information of order creation, and the return group describes the return process and customer service that buyers can enjoy.

3) set up

• New/Modified low code: define a contract group in metadata, including models/processes/configurations, etc., each configuration can be described by key path/configuration value types and restrictions, etc
• Hard coding: define the model class of the contract group in the business system, complete the writing and reading of the interaction with the content of the product contract, and explicitly obtain the low code of the business group instance in the business code: Set up a general framework of contract query > group resolution > configuration acquisition (cache is introduced to avoid repeated query). The business layer can obtain the configuration information in the corresponding group only through metadata description

2 Business Areas

model

1) specification

1. A business model describes a core business entity within a domain and is the only business instance that connects business processes and business components
2. Other models can be associated within a business model, but circular dependencies should be avoided
3. A complete business model description needs to include: data model, view model, business model/data model/view model transformation, business model repository, etc

Example 2)

Return business, based on the return order to promote the business process, business components from the return order to obtain the necessary business information, the implementation of return/refund/notice and other business functions; The return order is associated with a forward order, but the forward order cannot be reversely dependent on the return order; A return order model corresponds to a master receipt list and multiple return details. The warehouse is responsible for completing the two-way read and write of the business model <-> data model

3) set up

• Hard coding: write business Model (Model)/ data Model (DO)/ data interaction (Mapper)/ View Model (VO)/ Conversion layer (Converter)/ Repository, etc
• Low code: metadata description, automatic generation of DO/VO/Mapper/Converter; The repository component provided by the base can also automatically generate instances of the business model repository through metadata description

service

1) specification

1. Business service is a set of minimal business function units (methods) that are open to all users inside and outside the business field as a unit of interface aggregation.

2. Business services need a set of definition specifications (Annotation/AOP, etc.) with a clear and intuitive metadata description for each functional unit to achieve service discovery/document generation/permission management/stability assurance, etc. Metadata includes: business domain, business action, read/write, error code range, return value model, and so on

3. The input parameters of business services are limited to one sysParam and one bizParam. The former refers to system parameters such as call source/idempotency ID/ product code/tenant ID, while the latter refers to model parameters defined by each business

4. The business service is returned as Result, and the error code should be controlled within the scope of metadata description as far as possible, and no exception should be leaked to the caller. POJO or VO is recommended

5. The business service is not limited to the physical source of the caller. It only needs to add simple transformation logic in the docking layer to do authorization control

Write service implementation, need to have transaction management mechanism

Example 2)

Public interface DemoOrderService {/** * order * @param sysParam sysParam * @param bizParam bizParam * @return result */  @ApiFunction(apiType = ApiType.SUBMIT, funcBiz = "ORDER",funcAction = "APPLY", returnType = OrderApplyResponse.class, errorCodeType = CommonErrorCodeEnum.class) CommonResult<OrderApplyResponse> apply(ApiReqSysParam sysParam, OrderApplyInfo bizParam); }Copy the code

3) set up

• New/Modified definitions – Low code: Automatically generates interface+ Method + ErrorCode +POJO and so on based on metadata description
• Implement hard-coded: simple demand/not templated, unable to streamline the business requirements, direct encoding low code: for a standard process of service orders (on/applications/apply for a refund), the template is used to implement the contract group load – > configuration – > to load processes initialization (power, etc.) – > flow trigger – > results; For standard process advancement services (notification receipt/schedule advancement), templates are used for process configuration loading -> process triggering -> result processing, and so on. As more service scenarios emerge, there can be more templated business services.
• Use hard coding: As with all use of interfaces, assemble request -> Call -> process result low code: map current business objects/external parameters to POJOs of service input parameters based on metadata description and business configuration, template exception handling, and successfully returned results are mapped back to business objects or external responses in the same way

process

1) specification

1. Flow is used to describe a complete business process and promote one or more business sub-links based on a single business model

2. For the same type of business process of a single business model, there can be multiple Flow definitions to meet the customization requirements of different business models

3. Flow consists of transition, Component, and action. It works as follows: Each trigger corresponds to one action of the component. The Component whose actions are all successful completes, and the transition from component whose actions are all successful triggers a Flow and state transition of the business model.

4. The goal of Flow is to disassemble complex processes into multiple atomized business actions and decouple them from each other

5. Flow needs to be combined with the triggering of call entry such as business service/message/scheduling to realize complete process advancement

6. Flow relies on external callers to provide transaction management mechanisms (usually business services) and on business model repositories to control model loading and storage

Example 2)

3) set up

• New/Modified low code: The Flow itself is supported by the base component and only needs to be coded once; If business processes need to be defined, Flow configuration files can be dynamically generated based on business component templates and business models. With versioning and isolation mechanisms, you can prevent compatibility problems
• Use hard coding: Flow initialization scenario, obtain the required Flow configuration from the contract group of the current business field, initialize the process and advance it; Flow advance scenario, based on modelId+modelType+ Operate +request, can automatically trigger low code with template code: Through the standardization of Flow configuration in contract group, the Flow initialization scenario can also be achieved by template; When an existing business service needs to support a newly customized business process, it simply adjusts the configuration within the contract

component

1) specification

1. A business component is an aggregation of certain business actions and is designed for business functions, not limited to any one business model

2. The business actions of business components are the minimum atomized business units. The granularity is not mandatory but is measured by the degree of decoupling and reuse. It is recommended that they rely on one or more infrastructure/business services to provide standard business action implementations in a templated manner

3. For a business model, business components support controlled customization through open adapters (see infrastructure-Adaptation), or achieve exclusive customization in full copy (no reuse allowed for other businesses)

4. All core business logic, including but not limited to: parameter verification, business verification, reentrant/idempotency control, business model change, contract grouping change, calculation rules, external service interaction, etc., shall be incorporated into the business component layer and below (except simple business services without process)

5. Business components need a set of definition specifications (XML /annotation, etc.), with clear and intuitive metadata descriptions for the business actions and business models they support, to build business processes. Metadata includes a list of business actions, operate triggers, and a list of supported business models

Example 2)

• Core component definition class

  public interface BizModelDiscountComponent extends BizModelComponent {

  /** * occupy * @param context */ void occupy(FlowContext context); /** * return the discount * @param context */ void refund(FlowContext context);Copy the code

  }

• Core component metadata configuration

• Core component template implementation

For an explanation of the Adapter Adapter, see the “Model Fit” section

public abstract class AbstractBizModelDiscountComponent< T extends BizModel> implements BizModelDiscountComponent< T> { @Resource private DiscountApiService discountApiService; @override public void occupy(FlowContext context) {// TODO AdapterConfigInfo obtains from the current contract according to the context. context.getBizModel(); getDiscountAdapter().processOnOccupyResult( bizModel, discountApiService.occupy(getDiscountAdapter().toOccupyInfo(bizModel, new AdapterConfigInfo())) ); } @override public void refund(FlowContext context) {// TODO AdapterConfigInfo obtains the current contract from the context. context.getBizModel(); getDiscountAdapter().processOnRefundResult( bizModel, discountApiService.refund(getDiscountAdapter().toRefundInfo(bizModel, new AdapterConfigInfo())) ); } @SuppressWarnings("unchecked") protected BizModelToDiscountAdapter< T> getDiscountAdapter(){ return (BizModelToDiscountAdapter< T>) FlowInstanceFactory.instanceBizAdapter( "DISCOUNT", (Class< ? extends BizModel>) TypeUtils.getRealClassOfParameterizedType(this)); }}Copy the code

3) set up

• New/modified hard coding: new business components cannot be codized in a low way, and need to be developed with sufficient design thinking and overall view to achieve the initial version after weighing reuse degree and cost; With the development of business, the implementation of template-based business components is gradually abstracted. In many scenarios, if you cannot avoid complex customization logic, you can implement multiple design patterns such as policy/chain of responsibility/factory, which depends on the modeling ability of the developer and does not require low code: Existing business components are applied to the scenario of the new business model. If the standard template of contract configuration + adapter + infrastructure has been abstracted, only contract configuration is required (notification/kernel/on-chain scenarios are suitable)
• Use low code: Orchestration/discovery and triggering of business components in the Flow base, coding once; Complete the Flow configuration, that is, complete the assembly of service components

3 Infrastructure

Note: The infrastructure here is very different from the concept in DDD, so do not confuse it

statute

1. Infrastructure is a set of external service capabilities with high reuse, high cohesion and low variation as the unit (interface). It is the minimum functional unit (method) open to business services/business components.
2. Infrastructure can be the encapsulation of channel capabilities, such as external merchant channel services/cross-border channel services, etc. It can also be the encapsulation of a common technical capability, such as preferential service/commodity service/customer service, etc
3. The difference between infrastructure and business services is that the core functions of the former are usually provided by external services, and the core responsibilities within the current system are parameter assembly/scenario identification/return parsing and exception handling
4. The definition of infrastructure does not depend on external services. The input parameter is a self-defined standard POJO. The return value is encapsulated as Result, and the exceptions and service exceptions of external services are shielded

The instance

• Infrastructure – Information notification

  public interface NotifyGateway {

  /** * notifyInfo * @param notifyInfo * @return */ CommonResult<NotifyResponse> notify(notifyInfo notifyInfo);Copy the code

  }

Set up

• Add/modify hard coding: Infrastructure access is usually one-time, low code value is not readily available
• Using hard coding: In the caller code such as business services/business components, assemble the input parameters -> call -> parse returns low code: in business components, based on the adaptation mechanism described below, you can achieve: contract configuration + template-based business components, low code reuse of existing infrastructure

4 Model adaptation

gauge

1. Model adaptation is used to interface business models with infrastructure/business services, enabling two-way processing of model -> input and return -> model
2. In a templated business component, the invocation chain of adapters and infrastructure/business services is solidified, and component instances of each business model only need to implement corresponding adapters to complete business customization
3. Adapters are typically combined with product contract configurations to describe the mapping of business model -> infrastructure/business service inputs

The instance

Adapter – Business Model -> E-bank signature

public abstract class BizModelToDiscountAdapter< U extends BizModel> implements BizModelAdapter< U> { @Override final public String getType(){ return "DISCOUNT"; } /** * public OccupyInfo toOccupyInfo(U bizModel, U bizModel, U bizModel, U bizModel) AdapterConfigInfo configInfo); Public void processOnOccupyResult(U bizModel, U bizModel, U bizModel) CommonResult< OccupyResponse> result); / /... }Copy the code

• Order model for the Order, you need to use the preferential deducting the service, need to implement the adapter BizModelToDiscountAdapter:

  @BizAdapter public class OrderToDiscountAdapter extends BizModelToDiscountAdapter< Order> { @Override public List< ConfigDef> getConfigDefs() { return Lists.newArrayList( ConfigEnum.DISCOUNT_TYPE, ConfigEnum.DISCOUNT_TERM ); }

  @Override public OccupyInfo toOccupyInfo(Order bizModel, AdapterConfigInfo configInfo) {return new OccupyInfo(); } @Override public void processOnOccupyResult(Order bizModel, CommonResult< OccupyResponse> result) {// TODO recalculates the order amount based on the successful deduction} //...Copy the code

  }

Set up

• New/Modified definitions – Hard coding: defined for the first time when business components and infrastructure/business services are called, usually no change in implementation – Low coding: a flexible set of contract configurations can be used to describe the mapping relationship, and only configuration maintenance is required after the implementation of coding once; However, this relies on both dSL-level descriptive capabilities and requires designers of business models and infrastructure/business services, both with high abstraction capabilities and high cost
• Use hard coding: When business development abstracts templated business components, the first access is completed; When new infrastructure/service patterns emerge, adaptation needs to be made

Four summarizes

So much wordy to avoid being diluted by excessive detail on the subject. Finally, make a summary with a few questions:

1 where is the business design specification reflected?

In terms of architecture, we disassembled modules from product contract -> business domain -> infrastructure, and designed business protocols at different levels to constrain the responsibilities of each module. At the technical level, through multiple base components, the platform and business customization can be isolated to some extent, limiting the disorderly distribution of business details.

2 business design is only suitable without standards, why mandatory specification?

The purpose of the specification is not the standard itself, and the standards proposed in this article may not be appropriate for all problem domains. What I want to convey is that there needs to be some consensus and precipitation of business design within the team. On the basis of each iteration demand and each project output, continuous accumulation, continuous reconstruction and continuous optimization will be very helpful for the integration of newcomers/personal growth and team collaboration.

3. How to support business quickly and where to improve r&d efficiency?

To be clear, new business requirements do not result in significant performance gains or even some additional cost to meet design specifications. However, when multiple people collaborate, work is transferred, or parts of an existing function can be reused, unnecessary communication and maintenance costs can be reduced. For example, when a business requirement arises, the developer needs to make the following decisions:

1. Business model: Whether a new business model is required and whether an existing model needs to be adjusted
2. Service service: XXXXXXXXXXXX Service service, XXXXXXXXXXXX existing service
3. Business process: XXXXXXXXXXXX Business process, XXXXXXXXXXXX existing process
4. Service component: XXXXXXXXXXXX Service component, XXXXXXXXXXXX existing components
5. Infrastructure: XXXXXXXXXXXX Infrastructure, XXXXXXXXXXXX existing facilities
6. Product contracts/Contract groupings: Evaluate the assembly of product contracts and contract groupings based on the above judgment

The performance improvement is as follows: each module in the business domain is decoupled from each other, the R&D process is parallelized, and 1+1 can be equal to 2. The transformation scope is easier to locate, the resource evaluation is more accurate, and the progress control is clearer; For modules with frequent changes and high cost, targeted reconstruction is carried out to control the scope of influence; Many of the protocols mentioned above have the potential for low coding, which can further improve the efficiency of construction.

The original link

This article is the original content of Aliyun and shall not be reproduced without permission.