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://en.wikipedia.org/wiki/Widdershins
Just because it sounds cool.
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.
And he created Trello
Or is that just what you want us to think?
Same, using Chat GPT 4. It explained the steps without prompting, which is different from the single line answer shown in the post too. I got this…
Let’s break this down step by step:
Sally is one of those sisters for each of her 3 brothers. Therefore, the second sister that each brother has would be the same other sister.
This means that Sally has only 1 other sister, making a total of 2 sisters in the family (including Sally herself).
So, Sally has 1 sister.
Just move to Brixton
https://maps.app.goo.gl/hdEvTsPzTj8eYD5z5?g_st=ic
And if anyone’s not familiar, the song was written about this street.
A lot of Bruce Springsteen’s songs are like that, but I’ll recommend one in particular that hits your mark:
Brilliant Disguise. https://open.spotify.com/track/0nqbZ17t9v52SCemAm1QP0
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.