So what about ‘databases’?

Each Service Domain can be thought of as governing its own business information base that corresponds to its collection of active ‘control records’, see the Practitioner´s Guide for a more complete explanation of the association between business information and the underlying data structures and databases used to capture that information. Different Service Domains may choose to represent their business information using common data schema – indeed when business information is passed between Service Domains it is clearly advantageous if common data definitions and data views are used but each Service Domain will still govern its own business information and hence its own logical database partition. Two situations where common database technology is shared by multiple Service Domains are worth describing. Were Service Domains have common operational requirements or are assembled in the same business application it makes practical sense that they share the same data infrastructure, though from a conceptual design perspective their business information partitions remain discrete. In the second situation two Service Domains may have a highly active service exchange pattern, passing high volumes or high frequency data between them. In this case it can be more practical to eliminate the physical exchange of data altogether by having the two logical perspectives relate to the same physical data store (suitably architected).