I’ve always understood DRY to be about not duplicating concepts rather than not duplicating code.
In the example here, you have separate concepts that happen to use very similar code right now. It’s not repeating yourself as the concepts are not the same. The real key is understanding that, which to be fair, is mentioned in the article.
IMO, this is where techniques like Domain-Driven Design really shine as they put the business concepts at the forefront of things.
https://mitpress.mit.edu/9780262046305/introduction-to-algorithms/
This one is pretty hardcore. I bought the 2nd edition of it over 20 years ago when I started my career as a developer due to not doing a CS degree.
Also take a look at the Specification Pattern for something similar.
That’s something I would only use if the logic becomes very complex, but it can help break things down nicely in those cases.
Why the assumption that reactivity is only a front-end thing?
I’ve used it plenty on the back-end when dealing with streams of data that need to trigger other processing steps.
That guy with the mullet looks sharp
And he created Trello
As already mentioned, the blue book by Evic Evans is a good reference, but it’s a ittle dry. Vaughn Vernon has a book, “Implementing Domain-Driven Design” that is a little easier to get into.
Personally, I found that I only really grokked it when I worked on a project that used event-sourcing a few years back. When you don’t have the crutch of just doing CRUD with a relational database, you’re forced to think about business workflows - and that’s really the key to properly understanding Domain-Driven Design.