If you recently went through or reviewed the 2016 Unity Adventure Game tutorial and left with more questions about their design choices, this article is for you. Likewise, if you’re interested in the very different patterns you can use with ScriptableObjects, you might find this of interest too.

Two cases of interest here are how it models an RPG game’s “Conditions” and “Reactions” both as ScriptableObjects. But each piece of the game is modeled very differently:

I had been working in New York City for just over a year when I sat down at one of my favorite cafes in my neighborhood to write a personal journal entry. I gave it the title “On the crossroads between goal-oriented and process-oriented” and I wrote down stream-of-consciousness reflections on my life, career, and how I wanted to do things differently.

It was October 2015, and I had finished grad school and moved to NYC to work full-time as a Software Developer in a fin-tech company. I was having what I have come to see as the seminal quarter-life crisis many folks go through when they finish their formal years of education. I had been chasing goals all my life up until then, and now I had the luxury and privilege of deciding whether I should set another goal or do things radically different than what I had done so far. Goal-oriented versus Process-oriented, I called it.

One of the most transformative pieces of wisdom I’ve gotten in my career is Titus Winters’s ToTW #122 on test dataflow clarity. The Tip of the Week (ToTW) series offers advice focused on C++. Like Testing on the Toilet, which offers advice and best practices for software engineering at Google generally, it has become a fixture within the engineering culture, frequently cited in code reviews.

If you haven’t already, check out ToTW #122: Test Fixtures, Clarity, and Dataflow now—I’ll wait.

For many, Reactive programming seems like a conceptually elegant approach that falls apart the moment you try to do any serious programming. When adding essential error handling, refreshable state, etc. into an application, many folks see their codebases move further from the promise of clean, elegant reactive transforms.

It doesn’t have to be this way. While I’ve argued before for cleaner display of refreshable data by using AsyncPipe adopting better patterns for data refresh, this advice on its own does not provide an end-to-end pattern of displaying data from the moment it is loading all the way to error handling and refresh.

There’s a little-known pattern in software architecture that deserves more attention. Data-Oriented Architecture was first described by Rajive Joshi in a 2007 whitepaper at RTI, and again in 2017 by Christian Vorhemus and Erich Schikuta at the University of Vienna in this iiWAS paper. DOA is an inversion of the traditional dichotomy between a monolithic binary and data store (monolithic architecture) on the one hand, and small, distributed, independent binaries each with their own data stores (microservices, and service-oriented architecture) on the other. In data-oriented architecture, a monolithic data store is the sole source of state in the system, which is being acted on by loosely-coupled, stateless microservices.

I was lucky that my former employer also fell upon this unusual architectural choice. It was a reminder that things can be done differently. Data-oriented architecture isn’t a silver bullet by any means; it has its own unique set of costs and benefits. What I did find, though, is that a lot of large companies and ecosystems are stuck at exactly the type of bottleneck that data-oriented architecture is meant to resolve.