...
Ultimately, the data architects create a worksheet that contains the required attributes to complete an operation for a given entity for a given adaptor.
Eventhough Data Domains Can Be Multi-Demensional Doesn't Mean They Should Be
The JSON modeling tool with YOUnite is very powerful in that it allows a data architect to create very complex inter-dependencies between data domains but this should be avoided. However, when designing data domains, relational database principles should be followed. The following points illustrate a few pitfalls that need to be avoided when building data domains that have complex structure:
- If a domain domain has nested levels of nodes and arrays, its typically a good candidate for being broken out into multiple domains
- Arrays inside of a domain can create scope issues where one zone may not have scope to an entire array. Again, if this is a possibility, the array should probably be broken out into another data domain where governance can be managed.
To summarize, following sound relational database principles will create a master data ecosystem that has data records that are easier to manage and to apply governance to.
If an HTTP Operation Is Not Required for an Adaptor, Don't Analyze It
Example: There is never a situation where the analysts for the College Application system wants YOUnite to create (POST) a new student - they need to maintain control of that process so there is no need to analyze the required elements for a POST /student for the College Application system.
Generally Speaking, All Changes to
...
a Data Record Should Generate a Notification to All Adaptors Interested in That Data Domain
If that application tied to an adaptor has a well written RESTful interface it will allow you to register a callback for changes -- if not then you will need to discover a way to detect changes.
...