{ "componentChunkName": "component---src-templates-post-page-js", "path": "/2018/cryptomate/other-strategy-ports", "result": {"data":{"site":{"siteMetadata":{"title":"Solid Abstractions","siteUrl":"https://solidabstractions.com","twitterId":291334023,"author":{"fullName":"Julien Hartmann","profileHtml":"I am an open-source de­vel­op­er, for­mer IT con­sul­tant with a pas­sion for new tech­nol­o­gies. I be­lieve the role of an en­gi­neer is to em­pow­er peo­ple, by as­sem­bling sim­ple, re­fined de­signs.\n","links":[{"url":"https://github.com/spectras/","name":"github","title":"GitHub"},{"url":"https://stackoverflow.com/users/3212865/spectras","name":"stackoverflow","title":"StackOverflow"},{"url":"https://www.linkedin.com/in/julienhartmann/","name":"linkedin","title":"LinkedIn"}],"profilePicNode":{"original":{"src":"/static/profile-pic-301a9cbe7b572c3e7910c9717d2b3bcd.jpg"}},"url":"https://etherdream.org/about"}}},"markdownRemark":{"id":"45d3ccda-0b67-5ecf-a040-f7e80b5a2b7d","excerpt":"Remaining ports are much simpler in their scope, and in the fact they do not manage\ndynamic subscriptions. We will review them quickly for completeness.","html":"

Remaining ports are much simpler in their scope, and in the fact they do not manage\ndynamic subscriptions. We will review them quickly for completeness.

\n

--- excerpt ---

\n

Continuing the strategy port sub-series, we will now design the remaining ports.

\n
\n
    \n
  1. Market port.
    2. \n
  2. Trading port.
    3. \n
  3. Other strategy ports (this post).
    4. \n
\n
\n

Remaining ports are much simpler in their scope, and in the fact they do not manage\ndynamic subscriptions. They are setup at the start of execution, and stay essentially\nstatic.

\n

We will review them quickly for completeness, but there is not much challenge in their design.

\n

Port features

\n

History port

\n

The role the history port is to provide the strategy module with past market data.\nIt is used for three purposes:

\n\n

It is obvious from those purposes that the clients that read and write past data\nare completely uncorrelated. Following the\ninterface segregation principle,\nthis means we should have separate interfaces for reading and for writing.

\n

In fact, we could arguably have two reading interfaces, given generating a stream of events\nand crunching statistics on the whole dataset have very different performance, feature and…\ninterface implications. Yet I chose not to for now, knowing this will not matter until we\nhave large amounts of data to crunch. At this point we can come back and upgrade the design.

\n

Lastly, as the order book events are incremental updates, we must write a full copy regularly\nto serve as starting points for reconstitution.

\n

Apart from this subtlety, the history port interfaces are straightforward.

\n

Notification Port

\n

The role of the notification port is to give external tools visibility on what happens\nwithin Cryptomate. This could be leveraged eg. to send visual updates to end users, emails\nnotifications or charge accounts.

\n

This is not much to be said, the interface consists of a single method that emits\nnotifications to whatever the underlying adapter works with.

\n

Persistence Port

\n

The role of the persistence port is to keep a trace of transient state so, in the event\nthe system is restarted, running strategies may recover and resume from where they\nleft off.

\n

As strategies are not visible by this port, we shall use a\nmemento approach: the persistence port\nwill provide saving and restoring arbitrary data chunks, the meaning of which will\nonly be known to client code.

\n

It also needs a way to enumerate stored chunks so those can be used at startup.\nRelevant methods have been specified as an abstract class here.

\n

Conclusion

\n

This concludes the strategy port sub-series. It is an important milestone, as, if one\nremembers our architecture diagram, it means we have fully specified the trapezoids\nthat pull our modules together:

\n
\"Cryptomate
Cryptomate architecture diagram from the exploring patterns post.
\n

Thus, we have well-defined boundaries with well-defined contracts insulating modules from\neach other.

\n

We have successfully divided the project into meaningful parts, we will now start conquering\nthem.

","fields":{"isPage":false,"slug":"/2018/cryptomate/other-strategy-ports"},"frontmatter":{"title":"Other Strategy Ports","classname":null,"date":"2018-11-13T00:00:00.000Z","formattedDate":"November 13, 2018","isoDate":"2018-11-13T00:00:00+00:00"},"headings":[{"value":"Port features","depth":1},{"value":"History port","depth":2},{"value":"Notification Port","depth":2},{"value":"Persistence Port","depth":2},{"value":"Conclusion","depth":1}],"image":null,"series":{"name":"cryptomate","fullName":null,"fields":{"slug":"/cryptomate"}},"tags":[{"name":"architecture","slug":"/tag/architecture"},{"name":"ports","slug":"/tag/ports"}]}},"pageContext":{"series":"cryptomate","slug":"/2018/cryptomate/other-strategy-ports","previous":{"fields":{"slug":"/2018/cryptomate/trading-port"},"frontmatter":{"title":"Trading Port","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"},{"name":"ports","slug":"/tag/ports"}]},"next":{"fields":{"slug":"/2018/testing-aiohttp-client"},"frontmatter":{"title":"Unit Testing aiohttp Clients","series":"python"},"tags":[{"name":"code","slug":"/tag/code"},{"name":"testing","slug":"/tag/testing"}]},"seriesPrevious":{"fields":{"slug":"/2018/cryptomate/trading-port"},"frontmatter":{"title":"Trading Port","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"},{"name":"ports","slug":"/tag/ports"}]},"seriesNext":null}}, "staticQueryHashes": ["1733002695","4006707078"]}