10 Data Oriented Architecture
This chapter covers
- A way of thinking about the world
- The role of objects in Data Oriented Programming
- Drawing architectural boundaries
This chapter is about how to organize programs around data. That means, perhaps unexpectedly, that this is the chapter where we’ll spend the most time talking about objects. In data-oriented architecture, objects still reign supreme, but over a different kingdom than their usual one. We use them as gatekeepers with one purpose: exchanging data.
But beyond discussions about data and objects, the goal of this chapter is to give you a philosophy of architecture, something stronger and more bedrock than design patterns -- what Erlang’s creator calls “a way of thinking about the world.”
Or, as we’ll see, a way of thinking about worlds.
10.1 A small example
Let’s ingest some data. Here’s the setup:
Figure 10.1 The basic setup we’ll use to explore code architecture. It’s ambiguous by design!
Our service will read data from an external team's file store, lightly transform it, and then save it to our database. The data is standard finance stuff: Accounts, Invoices, and Disputes. Each month, this other team produces new files and then calls our API with a manifest describing where we can find them.
Listing 10.1 They call our service with a manifest describing the latest files
{
"accounts": "{uuid}.csv",
"invoices": "{uuid}.csv",
"disputes": "{uuid}.csv"
}