Contract testing verifies that a platform implementation continues to satisfy the interface and behavioral expectations of its consumers. At scale, it helps independent platform teams evolve services without sacrificing reliability or trust. section 9.0
Apply the technique as platform boundaries and capabilities evolve:
- Define the expected interaction between a platform team and its consumers. section 9.0
- Add fitness functions that detect architectural violations, such as bypassing a repository layer to call datastore functions directly. section 2.3.3
- Extend checks to custom APIs so cloud-specific features remain isolated from service logic as the platform adapts. section 2.3.3
Layered platform API
A service calls repository functions rather than accessing a relational or unstructured datastore directly. Fitness functions assert that handlers reach services, services reach repositories, and database access remains behind the intended abstraction. section 2.3.3
Listing 2.1 Fitness functions
teamDS := datastore.NewPostgresDatastore("team") #1 teamRepo := repository.NewTeamsRepo(teamDS) #1 teamService := service.NewTeamService(teamRepo) #1 teamHandler := handler.NewTeamHandler(teamService) #1 … // Fitness Functions // pseudocode - Modified example from [7] layeredArchitecture() #2 .layer("Datastore").definedBy("..datastore..") #2 .layer("Repository").definedBy("..repository..") #2 .layer("Service").definedBy("..service..") #2 .layer("Handler").definedBy("..handler..") #2 #2 .assertLayer("Handler").notAccessibleByAnyLayer() .assertLayer("Service").mayOnlyBeAccessedByLayer("Handler") .assertLayer("Repository").mayOnlyBeAccessedByLayer("Service") .assertLayer("Datastore").mayOnlyBeAccessedByLayer("Datastore")
The fitness-function listing makes the contract executable by expressing which architectural layers may access one another. section 2.3.3
