@joelv4495
💯. From a business perspective, we don't "create a shipment", we "SHIP an order".
@robotrabbit5817
Dude, there is so much nuance in everything about business software. I read so much stuff about software development and DDD and watched a lot of videos especially from your channel. And I am honest here. A lot of the time think I understood what you and those books are telling me and then I start programming at work on a real system and I make mistakes just to realize a few weeks later down the line that I was already told the solution to the problem. I am not sure how the rest does it, but everytime this happens I realize that I do not fully understand the underlying problems of the topics you and the books are talking about. I think this is why experience matters. I am grateful for your work on the channel. Thanks
@majormartintibor
I agree with you Derek, but would love to see how you design APIs that are not "CRUD/REST" for supporting business processes.
@transientwaveform1475
Louder for the people in the back!!! Systems built this way are wildly irresponsibly engineered in the real world, and yet it's so pervasive now because nobody challenges it because they assume it's "best practice" due to the tutorials they followed!!
@TheCardSlayer
What would an API example look like in these cases?
@funkdefied1
I love the square peg round hole. It’s been my intuition for a while, but I haven’t heard someone say it. I love thinking about my APIs as actions, RPC style
@Rick104547
Currently working on a microservices application that just crud for the most part. It's horrible, the UI around it has alot of logic in it because its basically a big leaky abstraction. So now my team is busy consolidating the microservices and designing the endpoints around behavior instead of crud based endpoints. The UI is getting simpler every iteration and as a bonus faster. It works for tests as well, we used to have tests for every single method but that was just dumb. Now we test behaviors and sure the tests are larger in scope but the actually test things that are of value and they give us alot of freedom to refactor. The only one that seems to have a problem with it is weirdly enough our solution architect. This slows down our efforts a bit but we still get it done.
@buriedstpatrick2294
I think CRUD is so prevalent because the first thing a lot of developers are taught to make is a TODO list app.
@allenbythesea
I've been opposed to the CRUD/REST paradigm since its inception. These concepts push business logic up into the UI instead of in the api/business layer. Glad to see others coming around as well.
@larsh8560
Vendors: "Our standard system have this great API you can use." Me: "That pile of turd? That's basically an APi wrapping CRUD operations on your database"
@adambickford8720
CRUD is so predominant because many times, that's all you genuinely need. In fact, it might even be the majority and you should use it if it makes sense. If you're just going to essentially validate the input of your endpoint and persist it... do that. Don't invent some abstraction (DDD, OOP, etc) 'just in case' or for the sole purpose of semantic decoupling. Sometimes a cigar is just a cigar.
@vuhoang5903
I've been learning and exposed to CRUD apps since day 1, and this opens a new horizon for me.
@commonsensedev
He is proposing Event Driven design, but CRUD exist behind it or with it How can you create an order without entering who made the order and list of items to order, and how will you do it without CRUD?
@cloudbaud7794
Need an end to end example
@lost-prototype
There are so many usual suspects of problems in CRUD systems, and it causes people to become so fixated on superficial DRY, high coupling, loss of context... The end is basically change data capture and never ending tack-ons to recapture lost context. CQRS/business operations.... Those are the way to go. Simple transaction scripts. Lean flows, even if there's a bit of duplication. You can always maintain multiple rich domain models. The bonus once you follow all the advice? Simpler test cases, higher level of certainty in the system.
@PhillippeLevidad
Great video as always! At the end, you asked why CRUD is so dominant in software development. I think it's because there are so many tutorials on building CRUD-based systems, and people are often just looking for step-by-step guides. The discussions you present are more philosophical and less practical in the sense that you're not always showing exactly how to implement something. A good example is how people often request videos where you refactor bad examples into good ones. This isn't a critique—I love these discussions. I get why you don't always show a practical code approach: "it depends." There isn't a single right way to do things, and your channel is called "Code Opinion" for a reason. Still, the abundance of CRUD examples and the lack of non-CRUD ones might be why it's so prevalent.
@GabrielSoldani
It probably doesn’t help that HTTP and REST were designed at a time that the Web that was mostly used to publish and consume documents, not to drive business processes.
@Leo-tf7gu
Ruby on Rails with it's Active Record ORM advocated this more than anything else.
@BenjaminHuarez
Whatever the case, if you model the software after the real world, and it stays maintainable and flexible, that's the solution which fits.
@anikaitmakkar989