I am developing an algorithmic trading framework using DDD/event-driven principles. I've decided the following components sit within my bounded context:
Data feed -> [Entry Point] -> "HandleData" command -> [Alpha Model] -> Insights -> [Portfolio Model] -> Targets -> [Execution Model] -> Orders -> [BrokerGateway]
Each model is a stateful (entity-like) computation. Other concerns (like performance reporting) can sit in another bounded context. Because I believe want transactional consistency throughout the pipeline (per data point ingested), I have created a single aggregate ("Algorithm"), which is composed of the above models:
Data feed -> [Entry Point] -> "HandleData" command -> [AlgorithmicTrader]
But this means that a single
AlgorithmicTrader aggregate now essentially encompasses my entire application (excluding the data feed and entry point).
I'm having a hard time splitting up my Algorithm aggregate for the following reasons:
- The prospect of having eventual consistency between the various pieces of the pipeline (e.g., the Alpha model having processed some transactions but the later stages having missed them) seems "very bad" to me, though I can't put my finger on exact reasons why. And in any case, this just means my entire application now has 3 (slightly smaller) aggregates vs. 1 all-encompassing aggregate.
- Unlike "textbook" aggregate cases (e.g., a
Productsaggregate where each
Productis an aggregate), my invariants don't align nicely along sub-dimensions like this. For example, you would think
Securitymight be a consistency boundary, but there are many transactions that cross securities (e.g., a relative value Insight that involves one security to buy and another to sell).
Is there an obvious aggregate design that I'm missing here? If not, is there an analytical framework or tool to help me refine the above aggregate design or to get comfortable with it being the best possible option?