LegacyTrain kata

Kata for code retreat on how to refactor a typical legacy code-base from an anemic, procedural & bugged domain to a DDD-style code powered by Hexagonal Architecture.

Note: this brown-field kata has been directly inspired by Emily BACHE's KataTrainReservation (green-field).

Context

TrainTrain is a start-up aiming to help passengers to smoothly reserve seats on national trains via their Web API. TrainTrain system is actually leveraging on 2 underlying Web Apis provided by the Hassan Cehef national train operator (to get trains topologies and to confirm seats reservations once found, and to get official booking references for those reservations).

A few months ago, a v1 of the TrainTrain.Api has been developed and released by an external consultancy but it seems that they are not interested anymore to work for the TrainTrain start-up. This is why TrainTrain has been calling you to code the new feature they want to add on their existing system.

Existing business rules around seats reservations

1. For a train overall, no more than 70% of seats may be reserved in advance.
2. You must put all the seats for one reservation in the same coach.

Objectives

Must-have

1. Introduce a new business rule:

   • "Ideally, no individual coach should have no more than 70 percent of reserved seats. This could make you and go over 70% for some coaches, just make sure to keep to 70% for the whole train."

2. Understand why TrainTrain is paying recurrent penalties to the Hassan Cehef national train operator

   • Seems to be related to an exagerated number of seats reservation cancellation unless it is related to a bug...

Nice-to-have

3. Embrace the Ubiquitous Language of the TrainTrain business within your code

4. Use as much as possible DDD tactical patterns (e.g. Value Types, Aggregates, Clojure of operations, ...)

5. Get rid of dead code or useless capabilities

6. Implement the Ports and Adapters (a.k.a. Hexagonal Architecture) so that the Domain code (i.e. the one with the business-logic) will remain properly isolated from the technical concerns (i.e. the cache, the http or Db calls).

   • Set a clear separation between business code & technical one by introducing 2 differents projects: TrainTrain.Domain and TrainTrain.Infra
   • No JSON stuffs must remain on the Domain side.
   • Introduce a completely different JSON format for another TrainTrain partner to interact with the TrainTrain.Api. Of course, the existing Web Api should remains for existing consumers. You will have to play with Ports and Adapters...

Platform architecture

TrainTrain & Hassan Cehef Web Apis interactions

To understand how to interact with TrainTrain or Hassan Cehef Web Apis, you can check Emily BACHE KataTrainReservation's readme.

Credits

This kata has been created by Bruno BOUCARD, Jérémie GRODZISKI and Thomas PIERRAIN for an exceptional DDD Paris event of 4 hours hosted at Microsoft France June 7th 2017. Vidéos (in french) with the keynote and the 3 live-coding sessions are available here on youtube.

Note: the domain (including samples, contraints and invariants) has been directly inspired by Emily BACHE green-field: KataTrainReservation.