Chapter 1. Introduction
The Problem Domain
Application development can be a deceivingly complex undertaking.
Not only must our programs do their jobs, they must do them well. There’s a laundry list of characteristics that Good Software implies:
Secure
Sound/maintains integrity
Scalable
Interoperable
Robust/resilient
Correct/functions as specified
And while these are all prerequisites to a finished product, not a single one is specific to any business. Across the world, programmers slave over their terminals, spinning up custom solutions to the same fundamental issues facing everyone else.
Bluntly put, this is a waste.
Breaking Up Responsibilities
For the sake of simplicity, we may categorize all code in a system into one of three flavors:
Core concerns
Cross-cutting concerns
Plumbing
Core concerns
The primary purpose of an application is to satisfy business logic, the set of rules that dictate its expected behavior. More simply, this is what a program does. For instance, an email client must be able to let its users read, compose, send, and organize email. All functions related to the fulfillment of business logic fall into the category of core concerns.
Object-oriented principles lend themselves well toward modeling business logic. Typically done via separation of concerns,[1] a related set of functionality may be compartmentalized in a module, with well-defined interfaces for how each component will interact outside of its internals (see Figure 1-1). In the case of our email client example, this ...