In Chapter 5, we briefly discussed the architecture of the bank example. In addition, we discussed the fundamental problems that arise when building distributed applications. In this chapter, I build on that discussion by introducing a set of basic evaluation criteria that will help you refine designs and choose between various design options.
Good code invariably has small methods and small objects...no one thing I do to systems provides as much help as breaking it into more pieces
—Kent Beck, Smalltalk Best Practice Patterns
The experienced distributed systems programmer will notice a certain bias in this chapter towards what I call small-scale, semi-independent servers. The “small-scale” part of this is easy to explain. By and large, I build servers with very limited functionality (as little as is reasonable, given the restrictions imposed by the fact that we’re building a distributed system). Then, I tend to give them large interfaces, exposing the same functionality in multiple ways.
As far as I know, there’s no knockdown argument in favor of this style of designing and building programs. Many programmers who have built object-oriented systems tend to agree with Kent Beck. In my experience, his quote almost holds for distributed systems as well—building small servers leads to flexible designs that evolve gracefully over time. However, there is a slight difference, due to network latency, for distributed ...