Anatomy of a Service Project - Part 2

The first iteration of a service project should be slightly different to the rest, while the aim of future iterations is to create functionality the aim of the first iteration is to define the interface, contract, tests and a stub. The purpose of this iteration is two fold

1. Formally define what the service is
1. Interface is what other services need
2. Contract defines how it should operate
3. Tests prove that it operates in that way
   
2. Provide something for others to call

By providing a stubbed interface you can work on a continual live basis in the rest of the application. This means that at an early stage you have provided an abstraction from one service project to another, which is critical if you want to add some parallel development and reduce the communication overhead of everyone talking to everyone else all the time.

There are a few rules for the stub

• It should reliably succeed or fail

For instance you might make a "login" method always succeed, whereas a "validate credit card" could be decided to always fail. The reason for doing this is that other people don't want to be debugging your service because you've decided to return random behavior. Remember its your responsibility to make sure your service works, not theirs. Most often you should make your service follow a "happy path" success route, if you want to go the extra mile its worth having two instances the "fail" and the "success" so at an application level you can use mediation to switch between the versions in your other service tests.

• It shouldn't do any real business logic

Don't spend all your time creating a test stub for everyone else's permutations... this is the actual functionality and you'll get there eventually, you want something out quickly that works.

• It shouldn't call anything else

Don't start accessing databases or calling other services

There are abilities to think about services as Mock Objects and all of those challenges, but that is really the job of the people calling the service to work out what they need. This leads to an interesting situation, other services will create mock versions of YOUR service to test against, this helps build the testing library based on their requirements rather you trying to create them.

So that finishes iteration 1, all that is required is to deploy the service to the test environment so others can start "using" it.

TBC...