wso2/reference-architecture

The Reference Architecture for Agility is a technology-neutral logical architecture based on a disaggregated cloud-based model.

Emerging Reference Architectural Patterns & Guides

A proven approach to helping every development organization become an integration agile organization. The Reference Architecture for Agility is a technology neutral logical architecture based on a disaggregated cloud-based model. It can be applied in incremental stages to create an integration agile foundation for any digital enterprises - deployable in private, public or hybrid cloud environments.

We welcome and appreciate any feedback, changes, or contributions. Please send a pull request, create a github issue.

• Cell-based Architecture (CBA) - Decentralized, Cloud native, Microservice compliant

  Functional capabilities grouped in an architecture unit based on scope and ownership. It is decentralized where data moves within and across cells and governance are transparently applied through a control plane embedded within cells.

• Layered and Segmented Architecture - API-centric centralized architectures

  The focus of the enterprises moved to API-driven with the digital transformation became the strategy. As a result, the business and the technical architecture moved from service-orientation to API-centric. The primary focus of this specification is to look at the architecture approaches taken by the industry and represent those patterns as generic reference architectures. We identified two reference architectures, layered and segmented which we will be discussing in detail in this paper.

  • Segmented Reference Architecture: Functional capabilities sub-grouped within layers based on organizational ownership. It is a centralized system where data flow moves from layer to layer.

  • Layered Reference Architecture: Functional capabilities grouped in layers by following a System of Systems view. It is a centralized system where data moves from layer to layer.

Architectural Guides & Concept Papers

• Platformless - Improving Enterprise Software Engineering with Platformless Computing

This paper introduces the 'Platformless' concept, emphasizing its intersections with APIs, cloud native mddleware practices, and platform engineering in the context of modern enterprise software engineering.

• Internal Developer Platform (IDP) - A Technical Reevaluation

Explore a comprehensive redefinition of the Internal Developer Platform, covering its scope beyond CI/CD and infrastructure automation. This guide offers in-depth architectural insights aimed at technical decision-makers and software architects.

Technology Specific Reference Architectural Patterns

• API-driven Microservice Architecture

• Cloud Native Architecture

• CIAM - A WSO2 Reference Architecture

• Event-driven APIs in Microservice Architectures

• A Cloud Native Digital Enterprise

reference-architecture's Issues

Are there any best practices for identifying the boundary of a cell?

Description:
Based on this architecture, defining the boundary of a cell is really challenging given the broader scope of a cell. It would be great to provide some best practices on defining the cell boundaries.

Can the "User" be another system or an application?

Description:
In the first section, the "user" is defined as a human interacting with the system. But in enterprise systems, there can be B2B interactions where an application or a system can interact with the system.

EI needs to be updated to MI

https://github.com/wso2/reference-architecture/blob/master/digital-enterprise-k8s-wso2-api-platform.md

Description:
Since EI has gone to End of Life this page needs to be updated to MI.

Suggested Labels:
Low

Affected Product Version:
EI 6.6.0
APIM 4.0/4.1/4.2

Am I already using CBA?

Description:
Hi,
I think what I have been calling Microservices, actually is Cell Based Architecture. Because I split my "services"(lets call this a boundry) into a set of smaller runnable services e.g. HTTP API (client based communication), GRPC API (internal based communication other than anything on the broker, using service discovery on a scaled service to send the message to), business logic worker, projections worker and a service for testing the boundary.
These smaller services are all deployed typically in one go, seperate deployables, as a boundary / version.

The query flow of this would be something like:

• user requests products to the products HTTP API
• products HTTP API validates the request and then from the read database and sends the data back.

The command flow is more like this:

• User requests to create a product to the products HTTP API
• Products HTTP API validates the query, does extra validation with the read database to see if the product already exists or not. Then fires a command (with the data) over the bus for any services that consume it. Sends a no content response to the user (to create a non blocking HTTP request)
• The business logic worker picks up the command adds the data to the event store, and fires off an event (can be many services consuming again) to the bus saying that it is successful in storing
• Both the HTTP API and Projections pick this message up
  -- The HTTP API says that the request was successful via websocket with data that is needed from the event
  -- The Projections worker adds the data to the read models.

Without going into much more detail, do you think this is the case?

Also please may I ask what you are using to create your diagrams? it looks clean and clear!

Thanks,
Jamie