Chapter 5. Re-architecting
This chapter covers
- Splitting a monolithic codebase into multiple components
- Distributing a web application into a collection of services
- The pros and cons of microservices
In the previous chapter we looked at techniques for refactoring—making improvements at the source code level. But refactoring can get you only so far, and sometimes you need to think bigger. In this chapter we’ll look at ways to improve the structure of the software as a whole by splitting it into smaller, more maintainable components. I’ll also discuss the pros and cons of splitting an application into multiple services, micro or otherwise, communicating over the network.
Don’t worry too much about the difference between refactoring and re-architecting. They’re really two sides of the same coin. The point of both refactoring and re-architecting is to change the structure of your software for the better without affecting the externally visible functionality.
Re-architecting is refactoring at a higher level than that of methods and classes. You can think of it as refactoring in the large. For example, when refactoring, you might move some classes into a separate package, whereas re-architecting might involve moving them out of the main codebase and into a separate library.
The main goals of splitting up an application, into either component modules or full-blown services, are as follows.