Problem: Designing at Differing Levels

You have a simple design problem: You're supposed to build a system that displays the state of a user's primary disk on his computer screen. This system must create a graph for the entire disk, displaying blocks on that disk in different colors to show their status: free, being used for a file, marked as bad, and so on.

This system shouldn't be hard to create, because you already know how to do the display function. You quickly identify which system calls to use, so getting the information to the display isn't hard either.

Building a monolith

You build the system as one big application, a monolith. The main program calls the display components to set up the display; then it iterates through the blocks of the disk, displaying each block's status. Pretty simple. In the end, you have a well-structured program that is best described as a monolith (see Figure 9-4).

images

Figure 9-4: A monolithic solution.

Just when you're about to schedule the demo for the customer, new requirements arrive. Now the customer wants to display the disk mapping for a different operating system, which means that all the system calls in the main program need to be changed and need to become conditional on the operating system. The customer also wants the option to display the data as a pie chart instead of as the bar graph you provided. The changes won't be hard to make, but ...

Get Pattern-Oriented Software Architecture For Dummies now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.