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.
First Contact main theme > all
So I deleted the story before I posted it, and began to realize that even though I’m 40, and should be past all this, it still hurts, and I’m a deeply broken person.
The thing about trauma (and it likely is trauma) is that it often just doesn’t go away on its own and you need to do work on it. So, why should you be over it?
Should is a loaded word as it pretty much always comes from what you learned as a child. You should do that. You should be like this.
That “should” probably comes from your father when he told you how you should be as a child.
It sounds like you aren’t over it now, but that’s ok. It’s ok not to be over stuff that happened in childhood. But the important thing to understand is that you can get over it with work. Being aware of that is the first step on that road.
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.