This looks like an example of why I'm trying to learn more about model driven development these days. There's probably a lot of wisdom in this file embedded in

This looks like an example of why I'm trying to learn more about model driven development these days. There's probably a lot of wisdom in this file embedded in a lot of noisy Go code. If someone tries to implement this code in a different programming language, a lot of this wisdom would have to be painfully extracted from the Go code. Some sort of extracted decision table format (examples [1]) would be objectively easier to read, could be rendered in different formats, hyperlinked, etc. Maybe a small subsection of this code could be generated from some structured data specification. Mbeddr [2] is an example of a language that allows embedding decision tables directly in C99. It can also embed state machines and other goodies directly into the code. This is just one way to go... I'm sure some ppl would complain about lock-in in a specific IDE. It is not clear to me exactly which domain driven techniques could be applied to this particular piece of Go code, but it could be worth it to find that out. From what I see out there model driven design seems to be applied to areas were really convoluted, and some times nonsensical logic needs to be mapped to code, like in insurance policy management, and stuff like that, or for other complicated code like firmware, drivers, protocols, etc. Why can't we apply these techniques to general programming problems? 1: https://medium.com/@markusvoelter/the-evolution-of-decision-tables-80ce77bf984c https://medium.com/@markusvoelter/the-evolution-of-decision-... 2: http://mbeddr.com/index.html http://mbeddr.com/index.html