Sure.

One might start out with a data model that corresponds to the physical pieces you'd find in the box. An object class for the territories, contained within an object class for the map, and an object class for the units and for the orders. The territory object would obviously contain pointers to the unit sitting on it, and the unit would need a pointer to the territory it sits on as well as a pointer to whatever order was issued, and the orders would need pointers to the territories listed. Standard object oriented stuff.

When the time comes to implement the rules, you end up using those pointers to find the next relevant order. So if you're trying to adjudicate the order "A ABC - XYZ", you need to look up the order given to the unit at XYZ. So starting from the order, you use its pointer to XYZ, then use that territories pointer to the unit U XYZ to get the order U XYZ . But soon you'll realize that the unit type object adds very little information, so you may as well merge 1 extra field into the order class and have the orders sit directly in the territory (representing both the unit and the order given to it). Once you've done that step, you start to realize that the territory class adds very little information as well. To find an order issued at a given territory is to have found both the relevant territory and relevant unit. So now all the physical objects that came in the game box are being represented by a single type of thing, an order.

The rules of the game are all basically about matching patterns. For instance, one rule is that when a supporting unit is attacked from outside the region it supports into, that support is cancelled. This can be written as "U TER1 - TER2 cancels U TER2 S U TER !TER1". Note that "cancels" is an adjudicative order meant for an invisible "GM" player. Instead of relating two things on the board like the other order types, it relates and order to another order. The sort of magic self-eating snake of Dipspeak is that it defines the game using the same objects that the game itself is played in. The "rulebook" is nothing more than an order set, no different than the order sets submitted by players as actions. When it comes time to write this rulebook of orders, you eventually have to write step 1: check that the orders each player issues corresponds to a unit that actually exists. But surprisingly you don't need a game state object to do this. Just like with the support rule, you can write an "is valid" rule by simply matching the orders against the orders of the previous turn. So the whole rulebook is just order matching all the way down!

Even the map and adjacency is defined with orders. The map is just a special page of rules for the submitted orders to match. For example Paris is defined by "A PAR * PIC/GAS/BUR/MAR" (translation: Army Paris something-to Picardy/Gascony/Burgundy/Marsaille).

Everything that is meaningful to discuss within the game can be defined with orders because the game itself is defined with orders. All there is is information which happens to be encoded in language.

Cognitively, we are all stuck in a skull opening letters, reading them, and sending letters out in response. Some of the letters just happen to be from sensory organs. Nothing outside of language is needed to define our reality, for our reality is language.