A service should exist to solve a problem
This article is follow up to my previous article, Thoughts about service granularity. It digs deeper into the idea that a service should only be added to an architecture if it solves a problem. I explore the idea that an architecture is the result of a series of design decisions, each of which solves a problem and modifies the architecture by adding, removing or modifying architecture elements. Consequently, you should be able to trace each service back to a design decision and the problem that it was intended to solve. Let’s begin by looking the concept of an architecture as a set of design decisions.