In this post we’re looking at domain models and how their use is supporting increasingly complex applications in capital markets and driving innovation, like the digitisation of ISDA contracts.
Data models – traditional concepts for designing applications
A data model or schema centres on a database in which data is stored in defined formats. A range of entities may be represented in the database as tables, columns and other secondary objects, with defined relationships between the entities. The entire configuration is termed a data schema.
Elements can be configured to work together in useful ways eg. users can save and re-use custom procedures and views. Within capital markets a trade could be represented by one or more tables with each table having defined columns, together containing all the data in relation to the trade eg. parties, asset type, price, collateral, timings etc.
With this traditional data schema approach a finely grained relationship exists between the data elements and any application built on top of them. One implication of this is that if you change the data definitions, the application must change to match. Similarly, if the application requires new features the definition of the dataset must also be changed. It’s a tightly bound relationship.
Secondly in order for a system to interact with the application it must know the full data schema. So this approach stands in the way of extensibility for third-party applications. This presented few problems for applications historically. However, in financial markets and other areas now using service-oriented architecture (SOA) other applications, concerned with [security, identity, business rules] increasingly want to consume this data in some way. So the type of relationship between applications and data formats can cause issues.
Domain model – building for extensibility and scalability
A more recent way to think about the application-data relationship is the domain model. Rather than a tables-based structure, the domain model expresses the arrangements of data as a framework of business objects reflecting real world processes eg. with financial markets business objects represent trading business processes. This approach is often termed ‘domain driven design’ (DDD).
For instance, a business process could be a trade capture followed by the trade’s confirmation, netting, netting confirmation, payment advice, settlement and then completion. These business processes may be further subdivided or grouped in a chain. In a domain model the expression of these processes is not tightly constrained. Instead they are seen as events within free-flowing operations. A schema may define how these events operate and relate to other elements but their interactions are not constrained by a database structure. Instead an event is ‘published’ with a series of elements that are expressed in an XML format. So the event producer could later add extra fields to the XML with no incompatibility issues for downstream applications, which could either consume those new fields or not and combine that with data from other sources.
Service Oriented Architecture
The use of domain modelling in IT stemmed from shortcomings in traditional client server models with data created for specific known applications. As applications proliferated, the growing need for cross-pollination was unmet due to constraints on database interactions.
This led, in the mid 2000s, to the rise of SOA. For the first time, applications were decoupled from database schemas and instead connected to services consuming and producing certain types of events.
The second generation of SOA – cloud-based and microservices – included asynchronous processes, allowing multiple events to be sent and received, delivering an end state irrespective of the event sequence.
ISDA – Applying the Domain Model in practice in capital markets
In 2017, ISDA – the International Swaps and Derivatives Association, began an initiative to introduce a Common Domain Model to derivatives and swaps activities – ‘common’ – because it presents a common (or standard) digital representation of events. The initial step was to codify, as a digital expression, the business processes which give effect to the long-standing standard ISDA contract and its variations. The process was then represented in XML format as an industry specific standard – now termed FpML (Financial products Markup Language). This allows applications to be written that are fully extensible with innovative features often unforeseen by the data creator. So, for instance, a bank can add custom requirements to the contract through a standardised digital process which the counterparty’s systems will recognise and accept.
In codifying the business process, ISDA enabled adoption of microservices architecture and SOA based systems. This facilitated the creation of discrete related services (not rigidly matching an underlying schema) which consume selected events and produce certain events. The application is flexible regarding which data is consumed or stored with the key requirement for connectivity being compatible data formats.
Extending the domain model
A common domain model approach works very well for interest rate swaps, credit default swaps and other derivatives. However, where structures are more complex the approach needs adapting. For example, at Baton Systems we sought to represent the eligibility criteria for collateral as a domain model in our Core-Collateral™ solution. The Common Domain Model worked to a point but it needed to be extended to describe additional processes.
Impact on performance – extensibility
Applications which are built tightly to a data schema are very efficient, achieving high performance on lookups, for instance. The downside is that the app is brittle – it can’t be easily adapted. With loosely coupled applications the data producer and consumer don’t need to know about each other and adaptation is easy if the dataset or business processes change. So, in summary, to facilitate extensibility, a domain model approach works really well.
Impact on performance – scalability
Let’s turn to scalability – the ability of a system to handle massive increases in the number of events. The systems in an equities exchange can deal with a billion events over 24 hours, sometimes compressed into a five hour window, with peaks of millions per second. In this environment tight coupling is likely to fail because the system cannot scale up and down asynchronously. Managing a producer or consumer failure, caused by a hardware fault, for instance is also important. Here we think about scalability slightly differently. The design should allow events to be consumed in parallel as much as possible. This is where common domain models and message-driven architectures really help. Our approach at Baton benefits from the advantages of domain-driven design.
To summarise: the key benefits of a domain model approach over a conventional data schema are:-
- Adaptability to changing datasets
- Fast, resilient parallel and asynchronous processing
- Extensibility – data is accessible and usable