Computers are different than humans.
I think we should be pragmatic and come with the best solution in terms of money/time/complexity. Not trying to mimick human thought using computers.
After all a truck isn't mimicking horse and carriage. A plane isn't mimicking a bird.
DDD does not necessitate OOP. You can do DDD in functional languages. I think there's a whole F# book about it. So I think you can conclude that OOP doesn't model the world well, which may or may not be true, but I think it's not valid to extend the conclusion to DDD. Is there a DDD-inherent reason why you think DDD does not work?
> And why do we even need to model something?
Well I suppose it depends on your definition of "model", but aren't you by necessity modeling something when you write software? Somewhere in your software there is a user thingy/record/object/type/dictionary/struct which is an imperfect and incomplete representation of a real life person. I.e., a model.
The real point is establish a common language to talk about the domain. This is enormously powerful. Have you ever worked with people who don't speak your language? Everything takes 3x as long as ideas aren't communicated properly and things get lost in translation.
It's the same with code. If your code is all written in the language of the computer then you'll be translating business language into computer language. This takes longer and it's more error prone. The business people can't check your work because they don't know how to code and the coders can't check because they don't know the business.
The point of building abstractions is it empowers you to write code in a language that is much closer to the language of the domain experts. DDD is one take but the basic idea goes all the way back to things like SICP.
With DDD you just get a third model that is neither the domain, nor the software, and both the domain experts and the programmers will have to work extra to maintain and understand it.
Worse, people often try to build this model up front, which means it will be wrong, hard to implement and probably get thrown away if you actually want to ship anything
I meant domain modelling in the simplest sense: I created three objects, the market, the trading strategy and a simulated version of the market. that's it. no paperwork, no forms filled in triplicate.
For example, at work I'm currently refactoring a test for parsing the CSV output of a system; as it stands it depends on hardcoded array indexes, which makes the thing a mess. Defining a few dataclasses here and there to model each entry of the CSV file, and then writing the test with said objects has made the test much more pleasant and easily understood.
But in a small project at work that's mostly about orchestrating infrastructure components around a big central configuration it's just that. You define some dataclasses, or in our case Pydantic models to parse APIs or JSON configurations because then you can use type-aheads based off of types and it's more readable.
And then, if you notice you end up having a lot of "compute_some_thing(some_object)", you just make it an @property on that object, so you can use "some_object.some_thing". If you often move attributes of some foo-object to create some bar-object, why not introduce an @classmethod Foo.from_bar or @property Bar.as_foo? This also makes the relationship between Foo and Bar more explicit.
OOP doesn't have to be the horrible case some legacy Java Enterprise Projects make it to be. It can also be a bunch of procedural code with a few quaint objects in between, encapsulating closely related ideas of the domain.
I did not model individual transactions, fees, etc as objects. The idea was that I encapsulated all the stuff that's relevant to a strategy in one object, and the market object would give me things like get_price(), buy(), sell(), which would also be available in the simulated version.
It's possible that it works for some people, but I've seen the above scenario play out too many times to see DDD as anything but a red flag
