This morning, while preparing a presentation for a developer audience not too familiar with Domain Driven Design, I realized that the first computer domain model I ever encountered was actually this game I played when I was in 5th grade: SCRAM.

SCRAM was a nuclear power plant simulator/game for the Atari 400/800, developed by the legendary game design guru, Chris Crawford. You were in charge of keeping a nuclear power plant running at optimal performance, while keeping it from melting down in the face of earthquakes and equipment failures. It boggles the mind that this game was written in 16K of Atari Basic (although, I looked at the source code as a kid, and it was full of assembly language packed in strings, which inspired me to learn 6502 assembly.)

In order to play SCRAM, worldly fifth grader that I was, I needed to learn the ubiquitous language of nuclear power: cooling towers, pumps, cooling rods, condensers, tertiary cooling systems, the NRC. In fact, I remember learned the word "tertiary" for this game. How cool is that!

While the NRC would not have likely certified me to run a nuclear power plan after playing this game, it gave me a very strong sense for how (at least in the model) a nuclear power plant works, something which I retain to this day. No wonder they had this game in my school!

I think domain modeling in business software has a lot of similarities to domain models in simulators. In fact, I think when we are building business software, all we are really doing is building a simulation of some business activity people used to do. In some cases, the model has been around for a while and the business has completely changed since people did it, but we're still kind of conceptually simulating what people would have done.

Too bad I can't get people at my work to see they are just playing games on a simulator. We'd have a lot more fun!