> [Abstraction heavy paradigms] structure the code around the description of the problem domain

My experience of Domain-Driven Design has been that it is extremely effective for driving conversations about the domain throughout the product life-cycle, but it produces frustrating codebases that are poorly attuned to the world outside the running process. Domain-Driven Design codebases want to be self-contained universes and treat external systems as details. OO design paradigms in general seem to have little respect for messages exchanged with external systems.

This wasn't true back when JavaBeans and object databases other distributed object systems were expected to take over the world, but the failure of those technologies shrank the OO world from distributed systems to isolated programs. These days, the messages exchanged with external systems are just data, without behavior. The marriage of data and behavior can only exist inside a single process. So object-oriented design turned inward and concentrated on the creation of rich inner worlds.

I think this is backwards, or at least incomplete. As Rich Hickey says, effective programs need to be situated in the real world. They are not ethereal abstract models. They have concrete functions, inputs and outputs. Having rich internal abstractions that mimic some aspects of reality is a means to an end, entirely subordinate to the purpose of executing interactions with other computing systems. Data-driven design embraces this reality. By treating data as essential, and behavior as something to be added when it is needed, it allows inputs and outputs to be first-class citizens.

> The data-oriented design approach doesn't build the real-world problem into the code. This could be seen as a failing of the data-oriented approach by veteran object-oriented developers, as examples of the success of object-oriented design come from being able to bring the human concepts to the machine

I think this perfectly sums up the confusion that OO modeling creates. You use code to write programs, or services, or cloud functions, things like that. The real-world problem that a program, service, or cloud function solves is interacting in a certain way with other programs, services, cloud functions.

The real-world problems that OO modeling paradigms want you to focus on are the domain problems. This is vitally important for design products, systems of programs that solve real human problems. If you are designing a system for managing medical records in a hospital, you need to model doctors, nurses, patients, labs, radiology images, patient stays, all those real-world things. However, when you are designing a piece of software to do one thing within that medical records system, the "real-world problem" your code is solving is limited to its role within the larger system.

Data-oriented design is a natural mental fit for writing programs or services that play a limited part in larger systems, which is always what you are doing when you are writing code. Object-oriented design wants to take on the complexity of the whole real world, which is the right perspective for product design and architecture, not for writing code.