CDM Design Principles #2422
Replies: 2 comments
-
|
The above guidelines are a good start on coding and low level design guidelines. I think that there need to be some higher level principles/guidelines on how the overall design should evolve, to improve supportability over time. I've appended my ideas on that below. In addition, we should have guidelines on how the design approach should work, e.g reuse of existing types vs specialization for differing requirements. This might fall under the category of "creating new types" above. CDM Supportability Goals and GuidelinesSupportability Goals To support CDM adoption and use, we have the following supportability goals for CDM.
Rationale: Financial systems that meet their mission can remain unchanged (except for reference data) for long periods of time, sometime over a decade. Firms developing based on CDM will not wish to invest resources in tracking new versions of CDM for functionality that has not changed.
Rationale: Developers using CDM want to protect their investment to continue to adopt new versions of CDM as CDM changes, otherwise they are not as likely to choose to build based on CDM.
Rationale: Once financial systems are put into place, it is common for them to stay in production for a long time. Firms deploying those systems are reluctant to invest money in adapting to new versions of underlying software and standards unless there is an urgent business need to do so, so underlying technology tends to change relatively slowly. We know of FpML-based systems that have been in production for close to 20 years, in some cases with little or no change to the core logic. Ideally it shouldn’t be necessary to change a CDM-based system that fulfills its mission just to interoperate with another CDM-based system that is based on a newer version of CDM. High Level Design Guidelines for Supportability The following guidelines are intended to support the design goals above. (Note that the existing CDM design does not meet all of the below guidelines.)
Rationale: It should not be necessary to adapt or regression test existing functionality against new CDM functionality just to take advantage of new reference data. For example, FpML reference lists have historically (over the last decade) changed around monthly, over 140 times in 11 years. (And each change typically affects numerous data values, often in several lists.) Production applications will need to be able to use that new data in a timely fashion without using new versions of CDM functionality, which may introduce new problems. Typically the time between definition of new reference data and its use in production is a few weeks or less.
|
Beta Was this translation helpful? Give feedback.
-
|
As mentioned in yesterday's TAG #2360, I suggest moving this discussion to being... a |
Beta Was this translation helpful? Give feedback.
-
With due consideration given to the Design Guidelines, https://cdm.docs.rosetta-technology.io/source/contribution.html, this section is intended to establish a set of domain design principles and sample scenarios to help guide contributors. The major sections of the design principles should include:
CDM Subdomain and Scopes
Types identify distinct entities and should be designed based on the MECE Principle. As such, types representing products or other classes should be mutually exclusive, meaning that no other Type in the same category can mutually exist. The second part of the MECE Principle states that entities should be collectively exhaustive. This principle means that an entity should fully encompass all elements that may exists exclusive of other entities.
The CDM core model should not include any specific type or attribute that identifies it with any regulation, organization, messaging system or vendor. Instead domains outside the core CDM should be associated through a proper class definition that broadly covers all subclasses and identities within that domain. Specifically, the use of FIX, FpML, ISDA, ICMA, ISLA, SWIFT, SFTR, MiFID should not be used within the core model, either structurally or in name.
Type and Attribute Naming Conventions
Enumerations
Enumerations should be in all upper case with no special characters except the underscore '_'. Enumeration phrases should separate words using the _ instead of running the words together.
Acceptable prefix and suffix phrases
The use of prefix and suffix phrases should be consistent in the definition across all primary data types where they may be used to define a subtype or modify an data type or attribute.
As an example, the use of Provision to modify a Termination refers specifically to a complex data type that contains attributes that are needed to properly define and execute an termination. Other phrases such as List, Schedule, Method would not fully capture the purpose. Prefix modifiers create a subclass of the primary data type. In this case, TerminationDate redefines Date. This approach creates clarity in the model as a opposed to using a Termination type with an attribute that defines it as a Termination Date and results in both data and structural consistency in the model.
Proposed list of primary data type modifiers:
Adjustment
Method
Provision
Calculation
Schedule
List
Terms
Specification
Representation
Reference
Choice
Range
Information
Beta Was this translation helpful? Give feedback.
All reactions