‎ > ‎

On why DoD isn't a modelling approach at all

posted Aug 22, 2016, 3:13 PM by Mike Acton   [ updated Aug 22, 2016, 3:27 PM ]

Q: Isn't Data-Oriented Design just dataflow programming?

Or: Why DoD isn't a modelling approach at all.

I'll quote an exchange with Christer Ericson's answer (with permission) on this subject:

No, not dataflow programming.

Dataflow programming, as well as OOD for that matter, is a modelling approach, and specifically for dataflow programming, by expressing data connectivity as a graph.

While neither me, nor Mike [Acton], nor Noel [Llopis] has ever provided an “official definition” of DOD (nor have we really been interested in doing so, nor would we necessarily 100% agree on one), I would argue that DOD is not a modelling approach, in fact it’s the opposite thereof.

As Mike has eloquently pointed out elsewhere, computation is a transformation of data from one form into another. DOD is a methodology (or just a way of thinking) where we focus on streamlining that transformation by focusing on the input and output data, and making changes to the formats to make the transformation “as light” as possible. (Here there are two definitions of “light.” Mike would probably say that “light” means efficient in terms of compute cycles. I would probably say “light” means in terms of code complexity. They’re obviously related/connected. The truth might be in between.)

I say this is the opposite of a modelling approach, because modelling implies that you are abstracting or not dealing with the actual data, but in DOD we do the opposite, we focus on the actual data, to such a degree that we redefine its actual layout to serve the transformation.

DOD is, in essence, anti-abstraction (and therefore not-modelling).

In practice, we find a balance between the anti-abstraction of pure DOD and code architecture component needs.