Contract first development paradigm

When I started writing code few years back I was constantly looking for constructive review comments and feedbacks by senior team members and peers.

As writing code is not difficult, even if you have not written a program before, you can easily do it with few google searches and little common sense. you just need to know what you want from your program to do.

One such a million dollar advice, I got when I was in early stage of my career was to always do “contract firstdevelopment”. In a typical fast development environment, every service/ module have dependencies on many other services and modules. If all of these services are getting developed in parallel then waiting for the completion of a dependent service will not only derail the development schedule but also increase cost due to unnecessary waits as a developer have to wait until his dependent work is not get merged, and costly maintenance due to hard coupling between components. In such cases “contract first development” is saviour. Contract first development stimulates development not only inter service but intra service logical modules also.

As a programmer when you have dependency on another module you should always first define the contract, this contract includes defining the responsibilities and functionalities of a dependent module. Contract should be defined not only for inter services communication but also modules within a service, i.e. configuration module and session modules in a service. As per dictionary definition a contract is a binding document between at least two parties that defines and governs the rights and duties of the parties to an agreement. When you identify there is a logical separation of responsibilities, these separations are called parties and they should honour a contract for communication. Contract first development promotes loose coupling hence extensibility and abstraction.

Lets understand how a contract first development can make better extensible softwares and faster development cycle using loose coupling.

Consider you are writing an application for an online store where system displays only those options to user which the user has permission and matches with user interest. for getting user interests and user role you are dependent on profile service, in case profile service development is already in progress and is not available for your disbursal instead of waiting for service you should define the contract with service and create a stub of the service for testing. Once actual service is ready, previous mock service can be replace with this actual user profile service. lets see this by example.

UserOptionsController{
 ProfileService profileService;
 getUserOptions(String userId)
   {
    if(profileService.getUserRole(userId) == ‘admin’) 
     return "all"; 
    else If (profileService.getUserRole(userId)== 'manager')     
    { return "read,write"; }
   }
}

To test above piece of code you need a working profile service instance, in case profile service is not available you can compile the responsibilities of profile service in a contract and refer to that contract everywhere. For functional testing of your service you can provide a mock instance of profile service which could be replaced with actual service when available.

Contract for profile service-

IUserProfileService{
String getUserRole(String userId);
List<String> userInterests(String unread);
}

Mock instance of profile service

UserProfileServiceProxy{
getUserRole(String userId){ return “admin";}
getInterests(String userId){
 return new Arrays.asList{“nature”, “photography”};
  }
}

In contract first paradigm we defined the contract first and any provider service will always honour this contract. As long as contract is being honoured we need not to care about which service version is being referenced, dependent service can always rely on the contract.