Code Notes

The source code is organized around principles described in Clean Architecture, by Robert Martin.

The core entities, game rules, and interactions that could be described as "user stories" are contained within the Game modules. The Game.Main module is the boundary for this module. It exports the entirety of the game interface and functions needed to execute user stories, and has no dependencies on other modules. This means that:

  1. All game functionality can be tested independently of the UI - in fact, it would be possible to delete the other modules entirely without breaking the game's functionality or tests.
  2. Implementing an alternative UI, even one using a completely different base library, could be done while only paying attention to the functions specifically exported by Game.Main.

The Component module carries the UI, defining the appearance and details about how input & output are delivered. That includes the aspect of time, which is treated as an input in this layer rather than as a core element of the game's rules. Although some of the components depend on others, the dependency graph and input & output of each is structured so that importing an individual component delivers everything necessary for instantiation.

The outermost / highest layers include Assets and Main. They are both very minimal. Assets provides for alternative character personas and images. Main loads the primary component with initial input.

Borrowing principles from Clean Architecture allows for clear boundaries between modules, preventing the pitfalls that arise from "spaghetti code" and the creeping rise of cognitive overhead. For a large code base, these same principles are be very helpful in ensuring that engineering teams can:

  1. Efficiently divide up development & maintenance responsibilities
  2. Adjust the scale of different components
  3. Test core business functionality independently of infrastructure details
  4. Adapt to major changes in infrastructure requirements without putting core business functionality at risk

I've seen several organizations struggle with the pitfalls of ignoring these principles. If you happen to be part of an engineering team that integrates them in your work, please be in touch; I'm in the market for both learning and good work.