Architecture Vision

The architecture vision page translates our business domain into the logical view of our architecture. What we mean by logical is it will capture less detail on the technology we're using (but may be influenced by it), and driven more by the problem domain. This page will also capture some of the high-level patterns that we adopt.

This document contains references to Domain-Driven Design, do refer to the official definition and reference if you want to know more about them.

Context Map

Context map shows all the different languages that we use within our domain. Unless indicated as a subdomain or bounded context, each oval represents both a subdomain and a bounded context for the simplicity of the diagram.

Bounded context is an important concept in our architecture as it is the base of the modularity of our architecture. They are normally derived from conversations and new business requirements. To dive deeper into each bounded contexts, check the Tactical Design section on the sidebar.

Notes:

• In practice, the types of Core, Supporting, or Generic from DDD is normally done on the subdomain level. We recognise that it's worth further emphasising the priority to be more granular into the Bounded Context, which is why the colour-coding has been applied to the Bounded Context level.

• In practice, the context map from DDD is normally drawn to reflect the reality. Because we're using the context map as a design tool here, we'll find the balance of the current state and target state.

Layered Architecture

The different parts of our architecture will have a different rate of change, and we need to make sure that a change in one part not to inadvertently break another. The layered architecture pattern organises our architecture so that each of the layers will have its own responsibility.

We are borrowing the layer names from DDD, Hexagonal Architecture, and extending the layers further to support our system needs. As much as we want to follow prior arts, there are shared jargons between different patterns. To avoid confusion between these different patterns, we may have named them differently, so do pay attention to the responsibilities outlined below as they may differ to what you're used to. These are the layers we have:

This pattern is to be applied to all bounded contexts, but may come in varying degree. It should be adopted rigorously for Core bound contexts and less for others. We need to pay attention to the cost of implementing the layers as it may not be natural for certain uses cases. Do shout if you feel some pain due to these layering!