Enterprise SOA design (2)-Component-Based Product Development Platform

In the previous article "Enterprise SOA design (1)-ESB design", we wrote that our SOA design is divided into two layers: one is the SOA design between systems, which is mainly completed through ESB; on the other hand, it is the SOA design within a single application system. This article will detail the latter.

 

Overall platform structure

In the product development process, in order to achieve greater granularity reuse at the business level, we need to vertically split the business and develop it in the form of business components, finally, multiple developed business components are combined to form the final software product.

Products developed based on components are built on a public product development platform. The platform provides all underlying facilities. The platform consists of two layers: technical platform and business platform. At the technical level, the platform provides a series of class libraries, frameworks, components, and tools, as well as corresponding technical support for service componentization. At the business layer, the business platform has accumulated a large number of well-encapsulated business components and some common business controls for selection when developing new products. The Platform also provides a series of other support for the entire software process, such as tools, designers, and management interfaces.

Is the overall structure of the Platform:

The figure lists most of the key components.

 

Component Integration Platform

For an independent business, we can encapsulate it into an independent business component and put it into the component library. Business components interact with each other in the form of services and events. To support interaction in this mode, the technical platform also needs to provide several technical frameworks: plug-in platform, service container, and event bus.

Is the component integration architecture:

• The technical platform provides the event bus and lightweight service bus.
• The component is developed in a domain-driven model and uses the domain Entity Framework as the basic framework. The components and components are also oriented to domain entities for interaction.
• Components provide component events and component services to other external components. External components can only directly call the services provided by components, or listen to component events.
• The component also provides reusable UIS and distributed services that can be directly used.
• After combining multiple business components, the entire application system develops some specific functions and UIS to complete a complete system.

 

Product Structure

Is a component diagram of a complete product:

Because our product development platform must support 721 customization, the same business component is also divided according to different general business levels: Organization common indicates the most common component of the organizational architecture, org Part1 indicates an Optional package of the organizational structure component. Customiztion can deeply customize and expand referenced business components without modifying the code of referenced components.

As you can see, for the entire product, some business components in the Business Component Library can be referenced to form the basic functions of the product. In the customer app component, the application system needs to do the work based on the component functions: complete the additional features of the product, and customize some components through the platform interface.

 

Internal component architecture

For a single business component, its internal architecture still adopts a domain-driven layered architecture:

Although the figure is large, it is not complicated, that is, the typical domain-Driven Hierarchy: distribute (DTO interface layer), application (Application Layer/domain logic layer), repository (warehouse) domain (domain entity ).

The focus is on the domain package, which includes not only domain entities, but also component events and component service interfaces, which are the core of the domain.

The underlying technical platform provides a series of support: IOC/AOP, attribute extension framework, domain Entity Framework, 721 customized framework, database generation framework, etc ......

 

End

In fact, in the componentized architecture design, the most complex thing is to analyze a well-encapsulated component, which users are to be oriented, and what requirements these users have for the component, how can this architecture meet these needs. For example, we have analyzed these aspects during the design process: the development requirements of components, the scalability of each component, the interaction requirements between components, the system integration requirements, the customization requirements of the project team, the external interaction requirements of the system, and the ease of use.

 

If you are interested, please contact us.