API-first
In Chapter 1, you saw that multiskilled, diverse engineering teams are better for serverless development. When such a team owns and operates its single-purpose product, it becomes the guardian responsible for protecting its contextual boundary by employing adequate technical and communication measures. API-first is a thought process and mechanism for implementing these measures.
Once you have identified and marked the boundaries of each subdomain, it becomes easier to answer the following questions:
- How can you protect the boundary?
- Who can get access to interact with the system?
- How can you grant access to external systems?
- What information can be transacted across the border?
To effectively accomplish these tasks, you must consider published interfaces to your application—that is, application programming interfaces (APIs). An API acts as an agreed contract for exchanging data without knowing the implementation details.
An API-first approach is about identifying, implementing, and publishing the inter‐ faces to the system you are building. The API becomes a first-class citizen and plays a significant role in the tactical design and evolution of the application. Figure 2-5 illus‐ trates a customer microservice with its API to perform defined actions. It promotes loose coupling and interoperability between multiple services within and outside the product domain.
Figure 2-5. A microservice inside a bounded context with its API for interaction
API governance and discoverability are the two most common issues enterprises face when several teams own and operate APIs. API portals often help discover and consume APIs in a self-service model. However, if you are just starting out with your API-first strategy and initial APIs, don’t get overburdened with these differ‐ ent processes, as they can be worked on in parallel as you create more APIs and gain experience.
Microservices-first
With a marked boundary (bounded context) and well-defined (micro) interfaces (API), it becomes easier to own and manage the implementation of the business logic. In this context, microservices offer a suitable development pattern to realize the domain logic. Each microservice has a purpose and identity. In most designs, you will find a microservice related to a bounded context as a one-to-one mapping, but that isn’t the only option. You saw in Chapter 1 that granularity is one of the unique characteristics of serverless. Utilizing the power of granularity, you can break down the problem domain within a bounded context into several smaller microservices, as shown in the card payments bounded context in Figure 2-6.
Figure 2-6. Mapping one microservice to a bounded context, versus multiple microservices
A microservice should be owned and operated by one team. Never have two teams share ownership of one microservice. This clear responsibility and business align‐ ment reduces the cognitive load on engineers, thereby increasing development veloc‐ ity and flow. Chapter 3 discusses designing microservices in detail.
