Next Digital Platform

This is the documentation site for the Next Digital Platform.

Application architecture overview|NetBank example

Design principles

The design principles behind the Next Digital Platform are:

• Autonomy: Domain teams should build and operate their applications autonomously, they should be able to make decisions about how to build and run their applications to best serve their business and customers. Their decisions should have minimal impact to other domain teams.
• Observability: To enable autonomy, teams need to be able to demonstrate to external stakeholders that they are effectively managing their environment.
• Deprecation and evolution: The platform should account for the expectation that different aspects will become obsolete and change over time. The platform should be constructed in a composable way that allows for the replacement of individual components without requiring a complete rewrite.
• Standardisation: Consistency should be encouraged for common patterns and technologies where they don't provide a competitive advantage. This will allow for greater mobility for engineers between teams, and teams between domains.
• Predictability: The platform should be predictable and easy to reason about both in behaviour and discoverability.
• Explicit reuse: Reuse is encouraged within a domain as the producer and consumer have the same accountability. Reuse across multiple domains should be explicit; the producer of the reusable component makes it available for reuse with the express knowledge that changes to their component may impact other teams.

Repositories

The current thinking is that a domain team will own a single repository with multiple applications that can be versioned and deployed independently.

It doesn't preclude the possibility of a team owning multiple repositories, but the current position is that a single repository should be adequate for Next Digital Platform applications.

Applications

An application should refer to a product or capability that can be released independently of other applications and not a discrete function or feature. For example:

🔴 Bad examples

• Accounts summary
• Transaction history
• Account details

🟢 Good examples

• Banking: accounts summary, transaction history, and account details are features of the banking application
• Investments
• User profile management

Intended usage

The intended usage for this repository is to clone or fork it and make necessary changes to configure your applications.

Here you will find a turborepo repository with the following:

• A docker-compose.yml to bootstrap the local development environment.
  • Configured with a local gateway that provides channel gateway functionality.
• Multiple applications that can be deployed independently.
  • docs: The docs application provides some context about how this repository is constructed. Delete this application when it is no longer required.
  • web: This is a sample web application which can be used as a starting point for new applications.
• Internal packages that can be shared across applications within this repository.

Note that this example includes integration with Auth0 as the authentication provider. The the web application is configured to require authentication, while authentication is optional with the docs app. The authentication behaviour is defined in the config/gateway/routes.yml file while the authentication provider is defined in the config/gateway/appsettings.json file.

Getting started

To get started, clone this repository and run the following commands:

pnpm run dev

Pre-requisites

• Docker
• NodeJS
• pnpm: npm install -g pnpm
• turbo: npm install -g turbo
  • Used to manage repo and app structure
• Access to ghrc.io/x15ventures container registry
  • Run docker login ghcr.io
    • Use your github username and a Personal Access Token (PAT) as the password
    • Ensure you have the read:packages scope enabled and that you have authorised your PAT with access to the x15ventures organisation

Creating a new app

Start by copying the apps/web directory:

• Change the name of the directory.
• Change the name of the application in the package.json file.
• Change the basePath configuration int next.config.mjs file.
• Add the application to docker-compose.yml file.
• Add the application to the config/gateway/routes.yml file.

This repository is designed to be a poly repo; not a mono repo, not a repo per app, but somewhere in between. It provides optionality to allow teams to organise their codebase as they see fit.