Object Oriented Design Basic Concepts

Reference from: 

Clean Architecture: A Craftsman’s Guide to Software Structure and Design Robert C. Martin

 You can see this clearly in Figure 17.1. The BusinessRules use the DatabaseInterface to load and save data. The DatabaseAccess implements the interface and directs the operation of the actual Database.

Figure 17.1 The database behind an interface

The classes and interfaces in this diagram are symbolic. In a real application, there would be many business rule classes, many database interface classes, and many database access implementations. All of them, though, would follow roughly the same pattern.

Where is the boundary line? The boundary is drawn across the inheritance relationship, just below the DatabaseInterface (Figure 17.2).

Figure 17.2 The boundary line

Note the two arrows leaving the DatabaseAccess class. Those two arrows point away from the DatabaseAccess class. That means that none of these classes knows that the DatabaseAccess class exists.

Now let’s pull back a bit. We’ll look at the component that contains many business rules, and the component that contains the database and all its access classes (Figure 17.3).

Figure 17.3 The business rules and database components

Note the direction of the arrow. The Database knows about the BusinessRules. The BusinessRules do not know about the Database. This implies that the DatabaseInterface classes live in the BusinessRules component, while the DatabaseAccess classes live in the Database component.

The direction of this line is important. It shows that the Database does not matter to the BusinessRules, but the Database cannot exist without the BusinessRules.

If that seems strange to you, just remember this point: The Database component contains the code that translates the calls made by the BusinessRules into the query language of the database. It is that translation code that knows about the BusinessRules.

Having drawn this boundary line between the two components, and having set the direction of the arrow toward the BusinessRules, we can now see that the BusinessRules could use any kind of database. The Database component could be replaced with many different implementations—the BusinessRules don’t care.

The database could be implemented with Oracle, or MySQL, or Couch, or Datomic, or even flat files. The business rules don’t care at all. And that means that the database decision can be deferred and you can focus on getting the business rules written and tested before you have to make the database decision.