![\"Cryptomate](\"/files/elements-58f08f8032f8aefb45ade0cc16e8a3a1.png\")
Module Diagram
We understand the problem and can start building our high-level architecture. We will start\nwith mapping the requirements to project elements.
\n--- excerpt ---
\nOur architecturally significant requirements workbook in hand, we are confident\nwe have clear enough understanding of the problem to start building our high-level\narchitecture.
\nOur goal now will be to map requirements to modules and components,\nexplore possible architecture patterns and\ndescend into details on critical points.
\nThis is a long step, as we will build the bulk of the design, so I decided to split this step\ninto multiple posts:
\n\n\n\n
\n- Modules and components (this post).
\n- Exploring patterns.
\n- Critical points.
\n
We will start with arranging our requirements as a set of modules. Each modules shall be\nresponsible for one requirement, or one group of requirements. For instance, Cryptomate\nshall be able to open, cancel and monitor orders on trading platforms: a trading element\nwould be in order.
\nHere are the modules I have identified:
\n| Module | \nResponsibility | \n
|---|---|
| Auditing | \nWrites down auditing trails. | \n
| Control endpoint | \nAuthenticates and authorizes user requests. Manages strategies according to user directives. | \n
| Market history | \nProvides random-access to past market events. | \n
| Notification | \nSends notifications based on user-defined rules. | \n
| Real-time market | \nProvides access to real-time market events. | \n
| Strategy evaluator | \nRuns user-defined business logic. | \n
| Strategy persistence | \nPersists strategy state so it can be recovered. | \n
| Trading | \nControls orders placed by the system. Provides events related to orders. | \n
As usual, if you found I missed one, please tell me.
\nThe way these modules get instantiated at run-time is interesting, to better understand the\nallocation mechanisms that will be needed:
\n| Module | \nAllocation | \nSelected By | \n
|---|---|---|
| Auditing | \nstatic, single | \nconfiguration | \n
| Control endpoint | \nstatic, single | \nconfiguration | \n
| Market history | \nstatic, single | \nconfiguration | \n
| Notification | \nstatic, single | \nconfiguration | \n
| Real-time market | \ndynamic, multiple | \nstrategy | \n
| Strategy evaluator | \ndynamic, multiple | \nstrategy | \n
| Strategy persistence | \nstatic, single | \nconfiguration | \n
| Trading | \ndynamic, multiple | \nstrategy | \n
Where static means the component is allocated on startup and destroyed at shutdown, while\ndynamic means allocations and de-allocations can happen during normal life of the system.\nMultiple allocations are the components that will have several instances coexisting during\nthe life of the system. For instance, the system might connect to several markets at once.
\nLastly, the third column details where the knowledge of what and how to instantiate components\nlives. In Cryptomate, it may either be statically configured within the configuration file,\nor dynamically decided by currently running strategies. This means both process will probably\nbe complex enough to mandate a specific builder module.
\nWe will therefore add the following modules to the list:
\n| Module | \nResponsibility | \n
|---|---|
| Configuration builder | \nInstantiates and initializes statically-allocated components from a configuration description (either a file or a data-structure). | \n
| Strategy builder | \nInstantiates or trigger the instantiation of components required to start a strategy. This includes the required bookkeeping to shut them down upon stopping the strategy. | \n
Since market events will drive most of our logic, and trading is inherently very time-sensitive,\nnow is a good time to picture how incoming market events will flow through our system, from\nmarket data providers all the way to outgoing trading orders:
\n![\"Market](\"/files/eventflow-4187b6381453dcbe02a009bc301884a3.png\")
We will be mindful of both ensuring the critical path has reasonable latency, and side processing\ndo not introduce spurious delays.
\nThis concludes our initial pass of identifying key Cryptomate modules. This is not set in stone yet,\nbut this should be enough for us to design our high-level architecture.
\nSo let's now explore architecture patterns we could use to structure\nthose modules into an actual design.
","fields":{"isPage":false,"slug":"/2018/cryptomate/modules"},"frontmatter":{"title":"Modules and Components","classname":null,"date":"2018-08-08T00:00:00.000Z","formattedDate":"August 08, 2018","isoDate":"2018-08-08T00:00:00+00:00"},"headings":[{"value":"Modularizing the requirements","depth":1},{"value":"Modules overview","depth":2},{"value":"Component allocations","depth":2},{"value":"Event flow overview","depth":2},{"value":"Conclusion","depth":1}],"image":null,"series":{"name":"cryptomate","fullName":null,"fields":{"slug":"/cryptomate"}},"tags":[{"name":"architecture","slug":"/tag/architecture"}]}},"pageContext":{"series":"cryptomate","slug":"/2018/cryptomate/modules","previous":{"fields":{"slug":"/2018/cryptomate/requirements"},"frontmatter":{"title":"Requirements and Quality Attributes","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"}]},"next":{"fields":{"slug":"/2018/cryptomate/exploring-patterns"},"frontmatter":{"title":"Exploring Patterns","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"},{"name":"pattern","slug":"/tag/pattern"}]},"seriesPrevious":{"fields":{"slug":"/2018/cryptomate/requirements"},"frontmatter":{"title":"Requirements and Quality Attributes","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"}]},"seriesNext":{"fields":{"slug":"/2018/cryptomate/exploring-patterns"},"frontmatter":{"title":"Exploring Patterns","series":"cryptomate"},"tags":[{"name":"architecture","slug":"/tag/architecture"},{"name":"pattern","slug":"/tag/pattern"}]}}}, "staticQueryHashes": ["1733002695","4006707078"]}