Sub-domains and bounded contexts
2024-01-01 | ๐ 206 words | โฑ 3 mins | ๐งพ History | โ NHS Notify | ๐ NHS Notify
Known Issues / Todo
- โ This page is draft and is subject to rapid change, and may not be fully accurate or complete
Sub-domains and bounded contexts
Bounded contexts are a pattern used in DDD to model parts of a system which operate on a single โunifiedโ model of part of a business domain.
For NHS Notify we are attempting to keep our architecture modular following DDD principles. As a starting point when creating new bounded contexts these are some suggestions for structuring the AWS accounts and components which are deployed within them.
- By default, each sub-domain has its own AWS accounts
<sub-domain>-preprod
(AKAdev
)<sub-domain>-prod
- Each sub-domain will have a top-level GitHub repo which defines the account-level infrastructure
- Each sub-domain will have one or more bounded contexts
- Usually this revolves around some store of state
- Subscriptions for events which affect that state
- Handlers and processing for changes to state
- APIs for direct actions on the state
- Events published to reflect changes to the state
- Auditing and logging to wrap the service and provide observability
- A sub-domain may contain one or more microservices
- Each microservice should be individually deployable with defined contracts between services
- Each microservice should be contained in its own GitHub repo