Why most of what I read about service-oriented architecture annoys me - Part 6

Let’s turn our attention back to the employee, branch, and document data that we will be storing in a SQL Server database. I said that how we arrange the data within that repository will be important. Here is a diagram depicting that arrangement.

 

 

 

We have tables for storing the branch data, tables for storing the employee data, and tables for storing the contract document data. If we look at it closely,

 

 

 

we see that there are no foreign key links between the tables for the branch data—outlined in red—the tables for the employee data—outlined in green—and the tables for the contract document data—outlined in blue. There are no such links because that would violate our principle by which data within different boundaries of trust should only be connected via processes transmitting across service interfaces.

 

Let us reflect on that state of affairs. Key requirements for our application is that it should record the arrival of shipments of documents at a branch, and record the issuing of documents to salespeople. Well, how is our application going to do that if we don’t have links between the branch tables and the documents tables, and between the employees tables and the documents tables? To answer that question, let us look at how the process of issuing documents to salespeople would function ...