Every API begins with the domain it serves. Before I write a single line of a definition I get clear on the business domain, the bounded context, and who owns it, because the domain is what keeps an API coherent as it grows. Getting the domain right up front is what stops APIs from sprawling into overlapping, redundant messes down the road.
Domains
Policies at this stop
GitHub Organization README
GitHub organization provide the ability to have a dedicated README, providing a single landing page for the API workspace of a domain, line of business, or domain, where all API contracts can be fo...
GitHub Organization Repositories
GitHub organizations provide teams with the ability to create repositories for managing API contracts, separating and organizing contracts by meaningful bounded contexts within a specific domain.
GitHub Organization Teams
GitHub organizations allow for the management of people and teams to help define who has access to repositories, contracts, and other assets managed via this dedicated domain workspace.
GitHub Organizations
A GitHub organization provides a dedicated workspaces for teams to produce APIs, organize all the API contracts in motion, and leverage source countrol, CI/CD, teams, and other resources provided b...
Maintainers
Require that every API names its maintainers, the real people or team accountable for its design, operation, and support, and records them where the contract lives. I care about this from the very ...
Teams
Requiring at least one product and one engineering, as well as other potential stakeholders involved through the API lifecycle from define to production, ensuring there is always someone actively o...