Composite UI for Service Oriented Systems – Data outside vs Data inside

This blogpost is part of a larger blog post series. Get the overview of the content here.

Before we dig deeper into the characteristics of a “thing” we need to talk about the explicit boundaries of a “thing” and what contracts actually mean.

Because a “thing” has explicit boundaries and only shares data with contracts and schema we need to differentiate data living inside the “thing” and data living outside the “thing”. Data outside a “thing” must be in a format so that both the sending and the receiving side understand the semantic of the data. Data inside a “thing” is private to the “thing and only loosely correlated to the data on the outside. “Things” do not know what is inside another “thing”. They understand the business process and the information which flows back and forth between the “things” involved in a business process. So a “thing” does information hiding of its private data. The data can only be accessed through interactions involved in the business logic of the owning “thing” of that data.

The implication of that design is that you can use any technology, programming language, storage technology and more you’d like inside the “thing”. You could even redevelop a “thing” completely as long as you ensure that the contracts and schemas shared on the outside remains the same. This means data in the inside of a “thing” is not immutable (or at least doesn’t have to be) and cannot be considered stable. But data on the outside of a “thing” needs to be both immutable and stable. What does that mean for your design? Well that’s a subject for another blog post.