Embracing a Data-Driven Approach in Software Design

Where Object oriented design and DDD lacks

Object oriented design (and by extension DDD) models the problem domain in code. As long as problem domain does not change, it is quicker to take decisions in Object oriented code. However, this coupling of problem domain and code causes an inherent friction when problem domain changes – which is often the case.

I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. - Joe Armstrong

Object oriented design forces developers to think in terms of houses and roads – the objects. With objects we don't know what is going on within the operations. On the other hand, if you were only dealing in maps, vector, trees everyone will understand the transformation.

When you see lists and trees, arrays and maps, tables and rows, you can reason about them and their interactions and transformations. If you attempt to do the same with homes and offices, roads and commuters, coffee shops and parks, you can often get stuck in thinking about the problem domain concepts and not see the details that would provide clues to a better data representation or a different algorithmic approach.

It is often the case, that in order to complete a business process, you need different pieces of data from different objects. OO makes it hard to merge this data into one entity to complete the process.

Another angle to this is, with map, trees and arrays make your data more homogeneous which lend itself to be processed by more generic functions.

Data Oriented design principles

Data isn't inherently linked to the problem we're trying to solve; it exists separately. Instead, we add meaning to data to transform it into information. In essence, data represents raw facts, while information is data imbued with context. For instance, when you consider the price of coffee in a database, that's data. However, when you introduce the element of time and look at the price from a week ago, it becomes information. This equation, "Data + Time = Information," highlights the transformative power of context.

By decoupling meaning from data, we gain the freedom to interpret and utilize it in diverse ways. This separation allows for flexibility in how we understand and apply the data. When we tightly bind data to specific classes or types, it becomes challenging to view it from alternative perspectives or use it in multiple contexts. This flexibility in handling data, liberated from fixed structures, can be a powerful tool in problem-solving and data-driven decision-making.

Unlocking Flexibility in Programming: The Data-Driven Approach

Object-Oriented Programming Fit: Object-oriented programming (OOP) works well when your program doesn't follow clear patterns, deals with a small amount of data, or handles very different types of data, like having unique classes for each type of thing.

Understanding Classes and Data: Think of a class or object like a box that holds information. How it works depends on how we understand the information it holds and how that information changes over time. The connections between different pieces of information are like solving specific problems, and we call these connections "meaning." But remember, the information itself is just raw data, like pieces of a puzzle.

Challenges in Traditional OOP: In regular OOP, it's tricky to separate this raw data from its meaning. When we want to change the meaning of a piece of data, we have to change the box (class) that holds it. This can make classes very locked into specific meanings, which can be limiting.

A Different Approach: To overcome this, we use a different method. Instead of keeping data and meaning together, we break them apart. We only give meaning to data when we need it to solve a particular problem. This makes us more flexible and allows us to change meanings without constantly changing how our classes are set up.

Instead of making special boxes (classes) to describe things, we use general lists (collections) that work for many things like customers, products, or orders. These lists are like dictionaries with names and information in them. What's different is that each list has different names and different kinds of information inside.

These lists work for everything. So, we can make tools (functions) that can change the lists without knowing exactly what's in them. For example, we can make a tool that checks if an email address is correct, and we can use it on different lists by telling it which part of the list has the email address.

Data-Oriented Design is a compelling alternative to Object-Oriented Programming, particularly when dealing with large datasets, optimizing for performance, and simplifying complex code. By focusing on the principles outlined above, you can embrace the power of DO and design software that's efficient, maintainable, and adaptable to changing problem domains. Or you could just use Clojure.