-
Notifications
You must be signed in to change notification settings - Fork 23
Logbook
This logbook will only focus on the project from the moment the mob has been constituted. In other words, we won't describe here the first 2 sessions where Tomasz and Thomas were alone to bootstrap this project.
Also, keep in mind that all those 'days' described are only 1:30 or 2 hours sessions each, of mob programming at lunch.
A Logbook entry written by @tpierrain
Cyrille and Ozgur have just joined the initiative and both of them have business expertise related to the SOR: they will be our domain experts!. Like Tomasz, Ozgur is working for the FX business line (and working on a real SOR system). Cyrille is actually the head of the front-office technical architecture (i.e. he's Thomas' boss), but has lots of business expertise in that area (as in many other within the bank).
Thomas & Tomasz introduced the project objectives to the 2 new joiners and we all brainstormed about it. The proper time to review what Tomasz & Thomas have been working on and to present ourselves (what we did before, and how we're connected to the SOR concept). We decided to experience the Mob programming way for the project.
A Logbook entry written by @tpierrain
We met with the mob and discussed about the responsibilities of a SOR. The proper time to clarify some terms and to start to build our Ubiquitous Language. We identify 2 different business contexts: one on the investor-side, the other on the market-side. We also clarify lots of vocabulary in the context of our project: is an "order" the same concept whether we are investor/trader-side or market-side? what's a market? an investor? etc.
We ended the session by cleaning all that have previously been done by Thomas and Tomasz and by restarting from scratch. We started to work on our first acceptance test (and have a debate about it). Since one of our value is low ceremony (see our principles here), we decided NOT to use Specflow for that, but to implement our acceptance tests as simple xUnit ones (for the moment). Our first user story and its first scenario are written our our wiki (the gherkin way), related code for this test is also written. Ding dong. End of the session.
A Logbook entry written by @tpierrain
Without Ozgur, but with an exceptional guest this time: @Cyriux, we continued our explorations.
After a short debrief on what we were doing to our guest-of-the-day, we made some domain distillation all together (using the always useful reformulation tool). Funny to see that Cyriux was asking pretty much the same questions as the one we asked ourselves the day before. E.g.:
- "You are talking about 'Orders'. Are the investor-side orders, similar to the market-side ones?"
- "No. But all the traders are using the same 'orders' terminology for both of them".
- "Can we talked about investor-orders and market-orders?"
- "No. A Market Order is already a specific kind of order (to conduct a transaction at the current market price)."
- etc.
Enough said & enough sandwiches: time to code!
Next step for the mob was to try to 'green' our very first acceptance test. Time for us to start digging below our acceptance test, to the unit-test level. Concretely speaking, it led us to work on our Market (mock) type. As of today, we needed this market to support 2 kind of orders for execution (i.e. market orders and limit orders). First unit tests for our Market mock/simulation, and green implementation for both of them quite easily.
While we were back on our first acceptance test that manages two Markets, we debated about CQS, Hexagonal Architecture, but mostly on how to design our SOR API:
In particular, we had to share the importance of a 2-steps order routing:
-
One step to create the identity of the SmartOrder & to be able to subscribe for further event notifications.
-
The second step to Concretely trigger the SmartOrder routing.
Crucial steps to prevent us from suffering from race conditions (e.g. if the OrderExecuted event is raised before we had the chance to subscribe on it).
Also, should we raise the Executed events from the Market itself? from the corresponding Order proxies? Ding-dong! end of our lunch session.
A Logbook entry written by @tpierrain
After a short clarification about the boundaries of our SOR's hexagon (for now virtual, since it's only in our heads ;-), we decided not to focus on the ports and adapters yet (e.g.: investor-side SOR external APIs), but to focus on the domain code that will be hosted inside the SOR hexagon instead.
We also continued to warm-up our mob programming efficiency. Indeed, after 3 times 2 hours of collective work only, we still have to learn how to communicate / understand each others, and to share a single keyboard. In other words, to build our team culture for the mob and the project.
Following TDD and the YAGNI principle, we continued to work in order to make our first acceptance test pass. On our way, we renamed the SmartOrder type to InvestorInstruction. Should it be a simple value object or an entity object exposing events such as (Instruction)Executed? We finally picked the second option, cause we found no relevant other place for raising such events.
To make this 1st acceptance test pass, we implemented the logic that tries to execute limit orders (on the markets) within the SmartOrderRouterEngine type, but this will more likely be migrated to the InvestorInstruction afterwards (or something else more cohesive and aggregated by the InvestorInstruction). Cause we clearly have a code smell here, with the SmartOrderRouterEngine explicitly raising the InvestorInstruction's Executed event).
After we green our 1st acceptance test and achieved a tiny related refactoring (RED, GREEN, REFACTOR), we added then our second acceptance test: ShouldExecuteInstructionWhenThereIsEnoughLiquidityOnTheMarkets(). This test illustrates our capability to execute multiple limit orders on various markets in order to fully execute the initial InvestorInstruction.
We started by adding the AllowPartialExecution option for orders and... Ding dong! End of the session.