The ultimate goal of any system is to provide maximum value for minimum outlay.
The principles to achieve this are Autonomy and Loose Coupling. Coupling is the degree to which each program module relies on each of the other modules. Coupling can be measured by observing the flow on effect when changing a module. Autonomy can be measured by how many different points of contact need to be made in order to affect a change.
Taking a simplistic view of a system, people see the separation between the horizontal layers of UI, Business, and Data and incorrectly assume that Autonomy and Loose Coupling can be achieved by separating on these horizontal layers. It does not; they come from minimizing the impact of change, which is generally achieved by keeping the impacts of a change within reach of the team making the change.
So, as the size of the system increases we retain Autonomy and Loose Coupling by maximizing the likelihood that a change remains within reach of the team making the change, and minimizing the impact on other teams.
If we separate on horizontal layers, any change to data will require teams from all layers to be engaged and coordinated. As an example, a name field would need a size limit implemented in multiple layers, therefore multiple teams. If the size changes, these teams would need to be re-engaged and re-coordinated. With multiple teams involved in the change, it is hard to determine who is in charge of the change. So, if we separate on horizontal layers, increasing the number of layers between the database and the UI increases the impact of change, and reduces autonomy.
Autonomy and Loose Coupling are achieved by analyzing the underlying model of the business in question, and aligning the system to the naturally occurring contours of that model. These contours outline the pieces of the puzzle that make up the business model. Each of these pieces is a service, and is assigned to a business unit owner. Each service can then be assigned to a cross-functional team of people. A guideline for finding these pieces – While the data may be similar, does it need to be consistent?
Given that each service is aligned with a business unit, questions of cost and priority can and should be made at a business level. Each service contains UI, Business, and Data layers and will evolve independently of other services, in line with business objectives. As such, extra capacity, or special performance requirements are dealt with as concerns internal to the service. For example, requirements such as increased disk capacity, data replication, or increased cpu can be dealt with to address specific circumstance, and at a business level. Investment can be attributed to business importance.
Interactions between services are realized as events. These events are what make up the external contract of the service. A guideline for defining events – Events are business level interactions, and should be recognized by business people.
Given that services have been designed around the level of consistency between the data, external events would generally only need only contain id’s, and occasionally dates. This has the benefit of reducing the surface area of change, which reduces both the likelihood and impact of change across multiple services.
There are two services that are exceptions to this rule – Branding, and ItOps. In essence, Branding is the interface to the human world, and ItOps is the interface to the machine world. Either of these two services can call in to other services, and can allow other services to call through to them.
Branding will provide a thin veneer within which other services can inject their UI. It will provide things like theming.
ItOps provides a similar thing for machines. A WebApi is an implementation within this service boundary.
This architecture allows for Auditing, Security, and Logging.
As an example, auditing can be accomplished by storing commands and events that are running through the system, as these are business related by their nature. A definition of messaging terms, in the context of this approach, can be provided on demand.
In line with this approach, a conscious decision has also been made to reduce interactions via the network where appropriate. Taking the attempt to impose a horizontal data services layer, it should now be evident that it will increase Coupling, and reduce Autonomy – going against the very things we are trying to achieve. Over and above this, it increases the surface area of the system in production, which increases the potential for operational issues. For example, contending with unreliable networks, network saturation, changes in topology, etc. A further discussion on this can be provided on demand.
· Four tenets of Service Orientation
· Fallacies of Distributed Computing