├── MSD-1-Use-Standard-Design-Process.md ├── MSD-3-Use-Jobs-For-Analysis.md ├── MSD-4-Use-Job-Story-Format.md ├── MSD-2-Scope-Design-Using-Key-Actors.md ├── MSD-5-Use-PlantUML.md ├── MSD-7-Collect-Feedback.md ├── MSD-8-Web-APIs-On-Top.md ├── MSD-9-Use-Event-Storming.md ├── MSD-10-Share-DB-Clusters.md ├── MSD-6-Seperate-Commands-Queries.md ├── MSE4-Healthcheck-Template.md ├── MSE1-Intra-MS-Comms.md ├── MSE2-Redis-For-Reservations.md ├── INF5-Use-Github.md ├── MSE3-Start-With-Templates.md ├── INF8-Use-EKS.md ├── INF1-infrastructure-as-code.md ├── INF9-Use-GitOps-Tool.md ├── INF6-Use-AWS.md ├── OPM-5-Microservice-Ownership.md ├── OPM-1-Decision-Tracking.md ├── INF10-Trafek-Ingress.md ├── OPM-4-Team-Design-Phase.md ├── INF7-One-Repo-Per-Env.md ├── MSE5-Faux-Git-Submodules.md ├── INF2-Use-Terraform.md ├── INF4-Github-Actions-CICD.md ├── INF3-CICD-Infrastructure.md ├── INF11-Use-Shared-Managed-DB.md ├── OPM-2-Limit-Team-Size.md ├── OPM-3-Team-Principles.md └── README.md /MSD-1-Use-Standard-Design-Process.md: -------------------------------------------------------------------------------- 1 | # MSD-1: Use Standard Design Process 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | 11 | ## Decision 12 | 13 | 14 | ## Consequences 15 | 16 | -------------------------------------------------------------------------------- /MSD-3-Use-Jobs-For-Analysis.md: -------------------------------------------------------------------------------- 1 | # MSD-3: Use Jobs as the Unit of Analysis 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | 12 | ## Decision 13 | 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSD-4-Use-Job-Story-Format.md: -------------------------------------------------------------------------------- 1 | # MSD-4: Use the Standard Job Story Format 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | 12 | ## Decision 13 | 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSD-2-Scope-Design-Using-Key-Actors.md: -------------------------------------------------------------------------------- 1 | # MSD-2: Scope Design Using Key Actors 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | 12 | ## Decision 13 | 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSD-5-Use-PlantUML.md: -------------------------------------------------------------------------------- 1 | # MSD-5: Use PlantUML to Discover Interaction Patterns 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | 12 | ## Decision 13 | 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSD-7-Collect-Feedback.md: -------------------------------------------------------------------------------- 1 | # MSD-7: Colect Feedback on your Service Designs 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | 12 | ## Decision 13 | 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSD-8-Web-APIs-On-Top.md: -------------------------------------------------------------------------------- 1 | # MSD-8: Web APIs are Layered on Top of Microservices 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | 12 | ## Decision 13 | 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSD-9-Use-Event-Storming.md: -------------------------------------------------------------------------------- 1 | # MSD-9: Use Event Storming Instead of Formal DDD 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | 12 | ## Decision 13 | 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSD-10-Share-DB-Clusters.md: -------------------------------------------------------------------------------- 1 | # MSD-10: Microservices Can Share Physical Database Clusters 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | 12 | ## Decision 13 | 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSD-6-Seperate-Commands-Queries.md: -------------------------------------------------------------------------------- 1 | # MSD-6: Seperate Service Endpoints into Commands and Queries 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | 12 | ## Decision 13 | 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSE4-Healthcheck-Template.md: -------------------------------------------------------------------------------- 1 | # MSE-4: Starting Microservices from Reusable Templates 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | 11 | ## Decision 12 | 13 | To implement a health-check endpoint, we are going to use the draft RFC and a Node.js implementation of it. 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSE1-Intra-MS-Comms.md: -------------------------------------------------------------------------------- 1 | # MSE-1: Avoid Microservices Calling Each Other Directly 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | 11 | ## Decision 12 | 13 | We don’t let ms-flights call ms-reservations to assemble the seating chart, and instead have the BFF API handle the interaction 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /MSE2-Redis-For-Reservations.md: -------------------------------------------------------------------------------- 1 | # MSE-2: Use Redis to Implement the Reservations Database 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | 11 | ## Decision 12 | 13 | Use Redis as the data store for reservations to leverage its unique simplicity and flexibility, characteristics fitting for the implementation of this microservice. 14 | 15 | ## Consequences 16 | 17 | -------------------------------------------------------------------------------- /INF5-Use-Github.md: -------------------------------------------------------------------------------- 1 | # INF-5: Use Github for Code Management 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | We'll need to decide how and where to manage both application and infrastructure code. 11 | 12 | ## Decision 13 | 14 | We'll use Github to manage code. Github is a poplular code management tool and we expect most readers and implementers to already have an account. 15 | 16 | ## Consequences 17 | 18 | No significant consequences. 19 | -------------------------------------------------------------------------------- /MSE3-Start-With-Templates.md: -------------------------------------------------------------------------------- 1 | # MSE-3: Start Microservices with Reusable Templates 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | 11 | ## Decision 12 | 13 | Use code templates to jump-start a microservice development in each programming language supported in your ecosystem. Using templates helps with speed of development 14 | without sacrificing quality, and keeps various microservices uniform in their key traits. 15 | 16 | ## Consequences 17 | 18 | 19 | -------------------------------------------------------------------------------- /INF8-Use-EKS.md: -------------------------------------------------------------------------------- 1 | # INF-8: Use a Managed Kubernetes Service 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | We plan to ship our microservices as containers and manage the container system with Kubernetes. We could run the Kubernetes system ourselves or we could use a cloud provider's managed Kubernetes service. 11 | 12 | ## Decision 13 | 14 | We'll use AWS' Elastic Kubernetes Service to manage our Kubernetes system. This will greatly reduce the complexity of setting up our infrastructure and will allow implementers to get started faster. 15 | 16 | ## Consequences 17 | 18 | AWS EKS is not free and using EKS will require implementers to incur billing charges - even if the services are not invoked. 19 | -------------------------------------------------------------------------------- /INF1-infrastructure-as-code.md: -------------------------------------------------------------------------------- 1 | # INF-1: Infrastructure as code 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | We need to decide how infrastructure changes will be made for the shared Microservices platform. 12 | 13 | ## Decision 14 | 15 | We'll use the principle of infrastructure as code for all infrastructure changes. That means that all changes will need to be serialized as code or configuration that can be checked into a git repository. 16 | 17 | ## Consequences 18 | 19 | No human operator infrastructure changes will be allowed. We'll need to invest in specialized tools and a language to treat infrastructure changes as code. Making changes will take longer than if we were to use a console or CLI. 20 | -------------------------------------------------------------------------------- /INF9-Use-GitOps-Tool.md: -------------------------------------------------------------------------------- 1 | # INF-9: Deploy Microservices Using a GitOps Deployment Tool 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | We need to decide on how microservices containers will be released into our Kubernetes system. This can be done manually, with scripts or through a dedicated tool. 11 | 12 | ## Decision 13 | 14 | We'll use ArgoCD as a deployment tool for our microservices containers and changes. ArgoCD is a GitOps tool and its declarative style of release managemnt fits well with other tool and pattern choices we've made on this project. 15 | 16 | ## Consequences 17 | 18 | Implementers will need to install and understand how to use ArgoCD for deployment. This increases the complexity of our infrastructure platform. 19 | -------------------------------------------------------------------------------- /INF6-Use-AWS.md: -------------------------------------------------------------------------------- 1 | # INF-6: Host Microservices in AWS 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | We'll be hosting Microservices in a cloud platform, but we'll need to decide which cloud platform to use. 11 | 12 | ## Decision 13 | 14 | We'll use AWS and its managed services for our up and running microservices system. We've had success with all the major cloud providers on projects, but we've decided to use AWS because it is popular amongst practitioners. 15 | 16 | ## Consequences 17 | 18 | Using AWS will result in a signficant amount of vendor lock-in, particularly when using managed services. This greatly reduces the portability of the solution. However, using AWS' managed services will reduce some of the complexity of the solution. 19 | -------------------------------------------------------------------------------- /OPM-5-Microservice-Ownership.md: -------------------------------------------------------------------------------- 1 | # OPM-5: Microservice Ownership 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | We need to decide on the relationship between our team structure and our microservices structure. 11 | 12 | ## Decision 13 | 14 | Each team owns one (or more) microservices. A microservice cannot be owned by more than one team. A single team owns decision making responsibility for its microservices and can operate it autonomously within the constraints of the system. 15 | 16 | ## Consequences 17 | 18 | Constraining and bounding ownership will help teams move faster, but will put added pressure on establishing the right team boundaries. If team boundaries are formed poorly, this will result in an unacceptable level of cross-team coordination. 19 | -------------------------------------------------------------------------------- /OPM-1-Decision-Tracking.md: -------------------------------------------------------------------------------- 1 | # OPM-1: Decision Tracking 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | We want to keep track of the key decisions we've made in the up and running Microservices build so that we know which decisions to re-consider in future builds. 12 | 13 | ## Decision 14 | 15 | We'll use Michael Nygard's Lightweight Architectural Decision Record format to log our key decisions. We'll manage the decision records as code and maintain a git repository to manage access and changes to them. 16 | 17 | ## Consequences 18 | 19 | The decision record will become an important part of our system documentation and will be a starting point for new team members. It will need to be continually maintained as new decisions are made and old decisions change to avoid drift. 20 | -------------------------------------------------------------------------------- /INF10-Trafek-Ingress.md: -------------------------------------------------------------------------------- 1 | # INF-10: Implement a Traefik Ingress Controller 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | Our microservices infrastructure will need a way to route messages from outside the newtork into sepcific Kubernetes hosted microservices. We'll need to pick an _ingress_ component that will do the message routing. 11 | 12 | ## Decision 13 | 14 | We’ll use Traefik to route messages from the load balancer to microservices deployed in Kubernetes. This aligns well with our use of Traefik in the development stages. 15 | 16 | ## Consequences 17 | 18 | We'll need to setup Traefik as part of our infrastructure environment, resulting in added complexity for our build. In addition, we may need to support propreitary Traefik instructions in our Kubernetes deployment files. 19 | -------------------------------------------------------------------------------- /OPM-4-Team-Design-Phase.md: -------------------------------------------------------------------------------- 1 | # OPM-4: Team Design Phase 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | We need to decide when to design team structures and coordination models. For example, should we design teams to align with a software architecture or the other way around? 12 | 13 | ## Decision 14 | 15 | We'll start by focusing on team structures before we dig into the design of the software architecture and microservices. This allows us to inform the microservices design by designing teams first. 16 | We'll also continually update and improve the team design throughout the life of the system. 17 | 18 | ## Consequences 19 | 20 | Starting with team design means we'll need a way to design team structures with an understanding of the impact to the software architecture and coordination model. 21 | -------------------------------------------------------------------------------- /INF7-One-Repo-Per-Env.md: -------------------------------------------------------------------------------- 1 | # INF-7: One Repository Per Environment 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | We'll need a strategy for managing our infrastructure code. We can create a "monorepo" and build all enviornments from it, or we can manage environment code independantally. 11 | 12 | ## Decision 13 | 14 | We'll create a Github repository for each unique environment that we are supporting. This will allow teams to own and operate their own infrastructure repositories in the early development and test phases. 15 | 16 | ## Consequences 17 | 18 | Maintaining multiple repositories will result in some significant synchronisation challenges. Teams will need to ensure that their environments are compatible with the production environment or problems will not be discovered until late in the testing stages. 19 | -------------------------------------------------------------------------------- /MSE5-Faux-Git-Submodules.md: -------------------------------------------------------------------------------- 1 | # MSE-5: Use Faux Git Submodules 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | 11 | ## Decision 12 | 13 | To check out repositories of individual microservices under the umbrella repository, 14 | we use the open source project Faux Git Submodules. The idea is to make it easy to 15 | descend into a subfolder of your workspace repository containing a microservice and 16 | treat it as a fully functioning repository, which you can update, commit code in, and 17 | push to. The basic intent is identical to that of regular Git submodules, except anyone 18 | who has used them knows that the actual submodules can behave unpredictably and 19 | tend to be major pains in the neck. Faux submodules, in our opinion, are much simpler 20 | and work more predictably. 21 | 22 | ## Consequences 23 | 24 | -------------------------------------------------------------------------------- /INF2-Use-Terraform.md: -------------------------------------------------------------------------------- 1 | # INF-2: Use Terraform for Infrastructure Changes 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | In [INF-1](NF1-infrastructure-as-code.md), we decide to adopt the practice of infrastructure as code. To be effective, we'll need to identify tools and patterns to support this method of operation and change. 11 | 12 | ## Decision 13 | 14 | We'll use Hashicorp's Terraform tool to construct and apply our infrastructure changes. Terraform uses a declarative model for changes which we prefer. Terraform is also popular amongst implementers and we've had success using it on projects. 15 | 16 | ## Consequences 17 | 18 | Using Terraform means that all our infrastructure code will need to be written in Hashicorp's HCL language. If we want to chagne tools in the future, we'll need to rewrite all of our infrastructure code to be compatible with a new tools' langauge. 19 | -------------------------------------------------------------------------------- /INF4-Github-Actions-CICD.md: -------------------------------------------------------------------------------- 1 | # INF-4: Use Github Actions for CI/CD Pipelines 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | In [INF-3](INF3-CICD-Infrastructure.md), we decided to incorporate CICD for our infrastructure changes. This requires us to select or build a tool to support this type of practice. 11 | 12 | ## Decision 13 | 14 | We'll use Github's Actions feature for our infrastructure pipeline. While there are plenty of good CICD tools available, using Github Actions allows us to reduce the number of tools that readers have to setup as they will allready be using GitHub for source code management if they follow the examples we've provided. 15 | 16 | ## Consequences 17 | 18 | Github Actions is not as mature as other dedicated CICD tools and relies heavily on a plug-in based ecosystem. This means that we'll need to continually evolve the pipeline as the platform itself changes. 19 | -------------------------------------------------------------------------------- /INF3-CICD-Infrastructure.md: -------------------------------------------------------------------------------- 1 | # INF-3: Use a CICD Pipeline for Infrastructure Changes 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | In [INF-1](NF1-infrastructure-as-code.md), we decide to adopt the practice of infrastructure as code, but we need to decide how we'll apply those code changes to the system. 11 | 12 | ## Decision 13 | 14 | We'll use the pattern of [continuous integration and continuous delivery](https://en.wikipedia.org/wiki/CI/CD) to apply infrastructure changes. This will be a dedicated pipeline for infrastructure changes that will exist in addition to any CICD pipelines that we deploy for the microservices code. Using CICD allows us to apply good code based change practices to the infrastructure code. 15 | 16 | ## Consequences 17 | 18 | Incoporating CICD will require a set of tools and good practices that can support automoation and testing of code changes. We'll either need to build these tools ourselves or find a tools that fits our needs. 19 | -------------------------------------------------------------------------------- /INF11-Use-Shared-Managed-DB.md: -------------------------------------------------------------------------------- 1 | # INF-11: Use Shared and Managed Database Services 2 | Date: 01-08-2020 3 | 4 | ## Status 5 | 6 | Accepted 7 | 8 | ## Context 9 | 10 | We need to decide on storage options and implementations for microservices. We could allow microservice teams to own and operate their own databases, or we could provide a shared database servcie that they can use. 11 | 12 | ## Decision 13 | 14 | The platform team will create Terraform-based modules to provision AWS hosted and managed database services for each environment. Microservices will have shared access to these database instance, but can still own and manage their own data and data structures. 15 | 16 | ## Consequences 17 | 18 | The platform team will need to own and operate the database services by coordinating with microservices teams. They'll need to ensure that the data services meet the needs of implementing teams and that the service is easy to use, reliabile, performant and maintained. Using a manged service helps to reduce the costs of this ownership. 19 | -------------------------------------------------------------------------------- /OPM-2-Limit-Team-Size.md: -------------------------------------------------------------------------------- 1 | # OPM-2: Limit Team Size 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | The size of the teams in our microservices system is an important factor for co-ordination costs and speed. Setting a team size limit will help shape how we structure teams and the services that they work on. 12 | 13 | ## Decision 14 | 15 | In our system, teams MUST have eight or less team members. If the team grows beyond this size, it SHOULD be split so that the team size can remain with the eight member boundary. The team size of eight is based on past working experience and anecdotal evidence from other implementers. 16 | 17 | ## Consequences 18 | 19 | Limiting our team size to eight will have a few side effects: 20 | 1. The scope of a team's work will need to be similarily bounded - this means that any microservices they own must be manageable for a small team 21 | 2. As the system grows, we'll end up with a large number of small teams 22 | 3. A large number of small teams will in turn produce a large number of small components and services 23 | -------------------------------------------------------------------------------- /OPM-3-Team-Principles.md: -------------------------------------------------------------------------------- 1 | # OPM-3: Define Team Principles 2 | 3 | Date: 01-08-2020 4 | 5 | ## Status 6 | 7 | Accepted 8 | 9 | ## Context 10 | 11 | In our system, we expect teams to be self-forming. But, in order to improve team effectiveness, we'll define principles that teams must conform to when they are formed. 12 | 13 | ## Decision 14 | 15 | Teams MUST follow the following principles: 16 | 17 | 1. Teams are [cross-functional](https://en.wikipedia.org/wiki/Cross-functional_team). Embedding a cross-section of skills in the team will reduce inter-team coordination and allow teams to make more autonomous decisions. 18 | 2. Team membership is limited to roles that directly influence the output of the team. Because we have a constraint of [8 team members](OPM-1-Decision-Tracking.md), we need to ensure that team membership is limited to roles that are highly releveant to a team's work. 19 | 20 | ## Consequences 21 | 22 | These principles are aspirational and subjective in nature. The effectiveness of team formation will ultimately rely on good decision making by those who form the teams and an understanding of the shared goal of the system. 23 | 24 | As a result, it will be important that team leaders are talented enough to make independent, autonomous decisions that align with these principles. 25 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | A collection of architectural decision records from the book Microservices Up & Running. These decision records use [Michael Nygard's LADR format](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) 2 | 3 | ## Operating Model 4 | * [OPM-1: Decision tracking](https://github.com/implementing-microservices/ADRs/blob/master/OPM-1-Decision-Tracking.md) 5 | * [OPM-2: Limit Team Size](OPM-2-Limit-Team-Size.md) 6 | * [OPM-3: Define Team Principles](OPM-3-Team-Principles.md) 7 | * [OPM-4: Team Design Phase](OPM-4-Team-Design-Phase.md) 8 | * [OPM-5: Microservice Ownership](OPM-5-Microservice-Ownership.md) 9 | 10 | 11 | ## Infrastructure 12 | * [INF-1: Infrastructure as code](INF1-infrastructure-as-code.md) 13 | * [INF-2: Use Terraform for Infrastructure Changes](INF2-Use-Terraform.md) 14 | * [INF-3: Use a CICD Pipeline for Infrastructure Changes](INF3-CICD-Infrastructure.md) 15 | * [INF-4: Use Github Actions for CI/CD Pipelines](INF4-Github-Actions-CICD.md) 16 | * [INF-5: Use Github for Code Management](INF5-Use-Github.md) 17 | * [INF-6: Host Microservices in AWS](INF6-Use-AWS.md) 18 | * [INF-7: One Repository Per Environment](INF7-One-Repo-Per-Env.md) 19 | * [INF-8: Use a Managed Kubernetes Service](INF8-Use-EKS.md) 20 | * [INF-9: Deploy Microservices Using a GitOps Deployment Tool](INF9-Use-GitOps-Tool.md) 21 | * [INF-10: Implement a Traefik Ingress Controller](INF10-Trafek-Ingress.md) 22 | * [INF-11: Use Shared and Managed Database Services](INF11-Use-Shared-Managed-DB.md) 23 | 24 | 25 | ## Microservice Design 26 | * [MSD-1: Use Standard Design Process](MSD-1-Use-Standard-Design-Process.md) 27 | * [MSD-2: Scope Design Using Key Actors](MSD-2-Scope-Design-Using-Key-Actors.md) 28 | * [MSD-3: Use Jobs as the Unit of Analysis](MSD-3-Use-Jobs-For-Analysis.md) 29 | * [MSD-4: Use the Standard Job Story Format](MSD-4-Use-Job-Story-Format.md) 30 | * [MSD-5: Use PlantUML to Discover Interaction Patterns](MSD-5-Use-PlantUML.md) 31 | * [MSD-6: Seperate Service Endpoints into Commands and Queries](MSD-6-Seperate-Commands-Queries.md) 32 | * [MSD-7: Colect Feedback on your Service Designs](MSD-7-Collect-Feedback.md) 33 | * [MSD-8: Web APIs are Layered on Top of Microservices](MSD-8-Web-APIs-On-Top.md) 34 | * [MSD-9: Use Event Storming Instead of Formal DDD](MSD-9-Use-Event-Storming.md) 35 | * [MSD-10: Microservices Can Share Physical Database Clusters](MSD-10-Share-DB-Clusters.md) 36 | 37 | ## Microservice Engineering 38 | * [MSE-1: Avoid Microservices Calling Each Other Directly ](MSE1-Intra-MS-Comms.md) 39 | * [MSE-2: Use Redis to Implement the Reservations Database](MSE2-Redis-For-Reservations.md) 40 | * [MSE-3: Start Microservices with Reusable Templates](MSE3-Start-With-Templates.md) 41 | * [MSE-4: Starting Microservices from Reusable Templates](MSE4-Healthcheck-Template.md) 42 | * [MSE-5: Use Faux Git Submodules](MSE5-Faux-Git-Submodules.md) 43 | 44 | 45 | 46 | --------------------------------------------------------------------------------