CRUD isn't for Complexity #shorts

Stop focusing on Entities and CRUD around those entities when you're in a complex domain. I'm convinced that CRUD causes complexity explosion and leads to a brittle system when you try and sprinkle in more and more domain logic. In a complex domain, focus on the capabaitlieis and workflows.

[OhhhThatVarun]

Didn't understand. Need an example. 😞

[event-sourcing]

Derek summarizing wonderfully what I've been trying to tell folks! 😂 This was indeed short, but more importantly it was concise. Will be sharing this a lot.

[adam-btxo]

Interesting! Could you please make a longer video on the topic with some examples? ☺️

[jessestruyvelt]

Wish it was possible, but sometimes, in some scenarios this just won't work. Like when the business has no real "standard" business processes. Like the insurance business over here, it's very loose. You can't put it in behaviors. Also the team needs to be willing enough to try it.

[nicholas]

Can't tell you how many times I've had to explain this in a job interview. At some point it's like, "Just hire me and I'll get it those problems sorted out for you."

[thedacian]

Whici is the boundry between complexity(DDD) and simple stuff|(CRUD)?

[RM-bgcd]

Great video! Would you say CRUD makes sense in public APIs such as Stripe when treating billing as a generic sub domain for example, since the core domain should contain the core business logic? Another instance of CRUD is when you intentionally want to implement a smart UI for whatever reason, even though it’s pretty much incompatible with DDD of course.

[alex_chugaev]

Good vid. Because real business logic is not just CRUD.

[andreasaagaard]

110%...

This is especially true when working with 3rd party services and you have to understand all the CRUD'y endpoints and the insane amount of hidden behaviour inside them...

It's a mess...

[mabdullahsari]

Would you consider creating a video on BDD?

[void_star_void]

I have more questions after watching the video than before

[quantrox]

"The system will be hard to changed" - there are a lot of systems which are not meant to be changed. I have been working in various domains - touristic, insurances, finances and others and didn't experienced such a problem. Of course, there were some problems with system flexibility but it was mostly a problem of bad design and low code quality but not of the kind described here. I had to maintain some CRUDs as well but they were not simple cruds, there were always some complexity in a domain and behaviour. I am more and more convinced to stop watching this kind of videos as such a generalizations like here are very limited to cases which may be hardly spotted in real life. I could misunderstood some of it, sure. But maybe it will be better to make a real life example - grab some complex code, refactor it towards your idea and then discuss pros and cons of this approach.