Home
Is a prototype of a Smart Order Routing (financial) system. The opportunity for a mob of Lunch-boxers, to explore -at noon- various technical approaches in reactive programming (Sequencer as presented at DEVOXX, LMAX Disruptor, RX, ...), but probably also Event sourcing, Hexagonal Architecture, etc.
Our exploration will be mostly based on Object Oriented language like C# because it's widely used and known by the .Net developers community. However, there will be a functional version with F# which will focus on highlighting the way of solving issues in a functional way. The choice of architectural approaches to solve problems might slightly be different. Let see what the future will bring...
This wiki hosts all information about this project, but mostly the result of our iterative domain distillation (DDD).
This wiki hosts all information about this project, but mostly the result of our iterative domain distillation (see. DDD). In particular:
- SOR in a nutshell
- The ubiquitous language of the project (including SOR definition)
- The result of our iterative Domain Distillation
##What's the point with this spike project?
Our goal is NOT to implement nor open source SOR (business) algorithms (and thus to be fired by our employer for confidentiality disclosure ;-).
Our goal is to spike and compare various ways of implementing a reactive application with a given level of complexity (various input and output types, latency constrained, ...).
By the way, we just pick one of the most complicated financial system to implement ;-) => the Smart Order Routing system to illustrate our explorations (with market data, order operations, execution reports, etc).
The analysis criteria will be readability & maintainability on one hand, and performance (latency/throughput) on the other hand.
Even if this is a spike, we will try to implement it following some principles:
- Test Driven: Every new feature is added following the TDD principles (testing behaviours) and targeting 100% Test coverage
- Domain Driven (DDD): by using the The ubiquitous language within our code, distilling the domain iteratively with the domain experts, relying on bounded contexts, etc.
- YAGNI: following this XP practice, we don't add any functionality until deemed necessary
- Clean Architecture: every architecture choice is motivated, and allows us to defer critical decisions for the project
- "Don't guess; measure": we stick to this rule in order to avoid any kind of confirmation bias and Premature optimization (cause remember: "it's the root of all evil" ;-)
- Low ceremony: we focus on efficiency (to deliver software) in our spike iterations. Normal, if we consider the fact that we work on that project mostly at Lunch time (indeed, we meet at noon to build stuff).
- We follow the 7 rules of a great git commit message. In particular, every git commit subject line should always be able to complete the sentence: If applied, this commit will {subject line here}
- We follow the default full set of StyleCop rules (with few exception for the test projects)
More than just sharing code, we will try to sum up and share our findings during our various journeys.
-
Journey0: Scoping of the various contexts related to the SOR (e.g. investors, markets, etc) + APIs related (market-side, investor-side), listing of the SOR responsibilities
-
Journey1: our goal for this first journey is to familiarize ourselves with the main concepts of SOR, and to implement a first and very simple SOR (mono-threaded, capable to cope with one execution strategy simultaneously, with everything located within the same .dll, etc.) -
Journey2: (TBD; but probably to make the SOR vertically scalable, allowing it to cope with multiple execution strategies simultaneously and with a proper performance test harness)
##A mob thing? Yes, this spike is done in best effort iteratively at lunch-time (we are all working in different teams within the same corporate & investment bank in Paris). We work collectively with sandwiches, but following the Mob Programming style.
Sor far, the mob programmers are (in alphabetical order):
- Ozgur DEVELIOGLU (@Zgurrr): developer, but also domain expert
- Cyrille DUPUYDAUBY (@Cyrdup): developer, but also domain expert
- Tomasz JASKULA (@tjaskula): developer and F# tweaker
- Mendel MONTEIRO-BECKERMAN (@MendelMonteiro): developer
- Thomas PIERRAIN (@tpierrain): developer
You can do it through the #SORLunchBox hashtag on twitter, or directly via our logbook entries:
-
LogBook (day 1 - day 4)
-
LogBook2 (day 5 - day 9)
-
LogBook3 (day 10 - day 12)
-
LogBook4 (day 13 - 15 => all about the Hexagonal Architecture thing)
-
LogBook5 (day 16 - day 17)
-
LogBook6 (day 18 - ...)
Since we are doing mob programming, the identity of the commiter is not relevant (XP code collective ownership).