Software Architecture

CREATE

VIEW

[
payment
].[
v_customer_contract
]


AS

SELECT

customer
.

customer_id
,

customer
.

customer_name
,

contract
.

contract_start_date
,

contract
.

contract_duration
,

billing
.

billing_date
,

billing
.

billing_amount

FROM

payment
.
contract

AS

contract

INNER

JOIN

customer
.
customer

AS

customer


ON

(

contract
.

customer_id

=

customer

.
customer_id

)

INNER

JOIN

payment
.
billing

AS

billing


ON

(

contract
.

contract_id

=

billing

.
contract_id

)

WHERE

contract
.
auto_renewal

=

0

Notice in the updated view shown in Example 6-2 that the join between customer and payment tables is removed, as is the column for the customer name (customer.customer_name).

Example 6-2. Database view to get open tickets in ticket domain for a given customer
CREATE

VIEW

[
payment
].[
v_customer_contract
]


AS

SELECT

billing
.

customer_id
,

contract
.

contract_start_date
,

contract
.

contract_duration
,

billing
.

billing_date
,

billing
.

billing_amount

FROM

payment
.
contract

AS

contract

INNER

JOIN

payment
.
billing

AS

billing


ON

(

contract
.

contract_id

=

billing

.
contract_id

)

WHERE

contract
.
auto_renewal

=

0

The bounded context rules for data domains apply just the same as individual tables—a service cannot talk to multiple data domains. Therefore, by removing this table from the view, the Payment service must now call the Customer service to get the customer name that it originally had from the view.

Once architects and database teams understand the concept of a data domain, they can apply the five-step process for decomposing a monolithic database. Those five steps are outlined in the following sections.

Step 1: Analyze Database and Create Data Domains

As illustrated in Figure 6-20, all services have access to all data in the database. This practice, known as the shared database integration style described by Gregor Hohpe and Bobby Woolf in their book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley), creates a tight coupling between data and the services accessing that data. As discussed in “Data Decomposition Drivers”, this tight coupling in the database makes change management very difficult.

Figure 6-20. Multiple services use the same database, accessing all the tables necessary for read or write purposes

The first step in breaking apart a database is to identify specific domain groupings within the database. For example, as shown in Table 6-5, related tables are grouped together to help identify possible data domains.