> I am not convinced that domain driven design works. Objects doesn't model the real world well.

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 difference is that modelling it through software gives you feedback, as you can run the software. You can't run the DDD documents.

Forgive my ignorance on DDD, but what documents are you referring to?

DDD isn't about objects. It's just about modelling the domain (real world) using the tools available to you. Some things are best modelled by objects, some are best modelled by functions or other constructs.

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.

Good coders learn enough about the business to check the code. Domain experts can look at the running software.

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 think people are getting triggered by the word domain, and conflating it with a particular cargo cult called DDD. It's the same with agile - the one that's implemented is usually the cargo cult version that charges you the cost of the "official" process without the benefits.

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.

At its core, objects are just containers for properties, and exploiting that fact leads to easily understood systems than the one without.

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.

This is how I treat it as well by now. I'm not even certain if it's object oriented, or not or hybrid, or not, or whatever.

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.

the model is for me. I wrote a crude btc trading bot, and I had three major objects: Market(), TradingStrategy and SimulatedMarket which used historical data.

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.

And if you can encapsulate the 3 different domains well, if you switch brokers you should have any external dependencies. Make your functions/domains deep.

IME mention of DDD has been a pretty solid predictor of "this project will produce nothing but documents for months and if it gets to the implementation stage complexity will spiral out of control. It probably won't ship."

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