Full model design choices
This page serves as a legend for the full model schema, explaining the choices behind some parts of the model.
Set of documents that describe the design of a set of additions/changes to the SOA. Serves as a space of storage for RequirementsDocuments (both business design and application architecture), and as a collaborative space to work on design-related topics.
Store design information related to one or more system(s)/service(s). Each document is produced as part of a Requirements set.
A specific class is defined for such documents so that each one of them can be independently linked to the anything that relate to it. For instance, as new projects will little by little add new requirements for a Service, we are able to retrieve all of these documents at once when browsing the Service.
RequirementsDocuments can be either business-oriented or technical, thus can be relevant to different user roles. The model stores this through "TargetRoles", allowing to display the document differently (or even hide it) according to the user.
Example: an SCA document should be imported with the "technical document" preset, that will automatically set the Architect & Developer roles to it.
Systems are usually a set of Services that are relevant to certain TargetRoles (more exactly, Systems can store anything within Services, Clients or other Systems). Thanks to this generic definition, any user can build a system that make sense to him (an application, an API, etc.). They could even be generated, like media players' automatic playlists.
The difference between Services and Clients is that clients cannot provide any web service. They are used to store, for example, "connectors" for developers, i.e. sources to ease the use of a web service ; they are also ideal to store Workflows that use web services, or even UIs over web services.
The distinction between Services and Clients is necessary to clarify the fact that no Service or Client can depend on it. Aside from that, they are managed in a similar way (both have implementations, both can be deployed, etc.).
We need to know which organization is responsible for a specific Service. It might be implemented as user groups, allowing to display the related Service differently if a user is part of the Provider group or not (= potential consumer).
TODO