Code Leader: Using People, Tools, and Processes to Build Successful Software

8.2. Data Contracts

Contracts in software can define things besides the interface presented to outside callers. Using well-defined contracts can also make working with databases or other storage mediums much easier and more transparent for developers. Not every developer is familiar with SQL, and even if they are, they may not be familiar with formal database design principles. When developers with this type of skill set design databases, they may not define them in the most efficient manner from a database perspective. One way to solve that problem is with data contracts. Decide what it is that needs to be persisted from the application's perspective, and make that into a data contract.

In the same way that interface does not dictate implementation, the data that an application needs to store does not dictate a specific database layout. Application developers can define their data contracts, and database designers or DBAs can dictate how that data gets stored in a database. That leaves app developers free to worry about application design without worrying about database storage, and it leaves DBAs free to optimize database storage for maximum performance, reliability, or disaster recovery.

Consider a typical order entry or eCommerce system. The application needs to be able to store records of customer orders. In C#, that data might look like this:

namespace ContractsInCSharp
{
    public class CustomerOrder
    {

public Customer Customer; public Address ShippingAddress; public Address ...