Reactive Architecture

Reactive means a series of design principles for creating cohesive systems, it’s mostly guided by the famous Reactive manifesto:

Responsive: This is the overall goal of the system, it needs to be responsive in any circumstances.
Elastic: The system needs to be responsive even under a ‘heavy’ load
Resilient: The system needs to be responsive under failure
Message driven: This is the key to achieve above goals

Reactive Programming

This is the difference between architecture and programming, architecture is usually a guideline/principles of designing a system, while programming is an implementation strategy of a reactive system.

It is event driven approach used in a single node/single micro service for data flow management and logic

For example, callback, declarative methods(map(), filter()).

Cool, then what is event driven:

An event listener must be attached to the event source in order to consume it.
An event represents an action/fact

Akka is a great example that practises reactive programming.

Reactive System

A reactive system is message driven, designed at architect level for cloud native, distributed system.

It can also be interpreted as a system that followed reactive architecture and its implementation may involve reactive programming.

Domain Driven Design

DDD is an architectural approach to design large systems which has similar goal as reactive system.

DDD has a systematic theory to architect a system, by saying this, you will see a lot concepts using DDD.

Identity Domains

Domain experts model the real business requirements to domains, a domain usually defined based on business context/knowledge, for example, in a retail company, Shipping department is a domain, inventory is another domain.

Make Ubiquitous Languages

Use a ubiquitous language to understand business or idea, to communicate between software developers and domain experts, ubiquitous language maybe different between different domains, because it is used to communicate inside a domain.

Bounded context

When a domain is complex enough, it should be further break down to sub domain or a bounded context.

Now we can talk about how to identify domains, event storming is one way to achieve this, domain experts gather in front of a white board, listing out all events/activities that can happen in the system using using subject-verb-object notation.

Domain Activities:

Some common types of domain activities include:

Command: This means initiate a request, for example, register an account.
Query: This basically means the request to retrieving information and expecting to see the result.
Event: This means the fact that something happened in the past, for example, user account created.

Domain Objects:

Value: A piece of information that is immutable
Entity(unique, mutable): This can be designed as a micro service.
Aggregation root:

Others

Domain abstraction: service(stateless), factory(create object), repository(delete object)
Anti corruption layer: to keep bounded context boundary clean and maintain purity

Visualizing Software Architecture

C4 model is one way to visualize the software architecture, it uses 4 level to guide you top-down visualization of a system.

Context: The highest level of the architecture.
Container: A container is a deployable functional unit inside the context.
Component: A functional part of a container, it can be a module, lib etc.
Code: This is very similar to the data modelling

Domain Driven Design 101