Service Domain Model

This is the sixth in the sequence of blog posts regarding some of experiences in creating Trading and eCommerce platforms at Adaptive. The previous post can be found here.

In this post, we look at how the Parse Tree generated from our Service Definition DSL can be transformed into a Domain Model that can be reasoned about and further transformed into useful artefacts.

Transformation

The process of transforming a Parse Tree into a Domain Model can be achieved using the Visitor Pattern. Using this technique you recursively walk down the Parse Tree building up the Domain Model in parallel as you descend.

Model

Here we set out the Domain Model that is generated. We have presented this as a set of pseudocode interfaces. For each interface, there is a summary and a description of the various properties.

The Model interface encapsulates the whole Domain Model. It consists of a Namespaces property, a collection of Messages and a collection of Services.

Namespaces

The Namespaces interface defines the various namespace strings to be used for each platform when it comes to generating code.

Message

The Message interface is an abstract representation of a Message. Each message has a unique name and a MessageType.

The MessageType enumeration defines whether a concrete message is COMPLEX, i.e. made up of a number of fields or and ENUMERATION.

The ComplexMessage concrete interface extends the abstract Message and introduces a collection of Fields.

The EnumerationMessage concrete interface extends the abstraction Message and introduces a collection of enumeration values.

The Field interface is an abstract representation of a Field. Each field has a unique name a type and flags to specify whether it’s optional, required or repeated.

The FieldType enumeration defines whether a concrete field is PRIMITIVE, i.e. a boolean, string, double etc. of a nested Message.

The MessageField concrete interface extends the abstract Field and introduces a nested Message.

The PrimitiveField concrete interface extends the abstract Field and introduces a PrimitiveType.

The PrimitiveType enumeration defines a set of primitive types that are then mapped to concrete types that are idiomatic to each platform.

Service

The Service interface defines a service in terms of a unique name and a collection of Operations.

Operation

The Operation abstract interface represents an operation with a name that is unique for the parent Service and an OperationType.

The OperationType enumeration defines a set of operation types that conform to the various messaging protocols.

Request Response Operation

The RequestResponseOperation concrete interface extends the abstract Operation and references the request and response Messages.

Request Only Operation

The RequestOnlyOperation concrete interface extends the abstract Operation and references the request Message.

Stream Operation

The StreamOperation concrete interface extends the abstract Operation and references the update Message.

Request Stream Operation

The RequestStreamOperation concrete interface extends the abstract Operation and references the request and update Messages.

Publish Subscribe Operation

The PublishSubscribeOperation concrete interface extends the abstract Operation and references the request and update Messages.

Summary

In summary, we have described how a Parse Tree can be transformed into a Domain Model by recursively walking the tree using the Visitor design pattern and generating Model objects in the process. We have also defined a set of interfaces that can be used to model such a domain.

The next post can be found here.