Sort of. What you are describing is cohesion--the Common Closure Principle. "Only the OrderProcessing Module should deal with Orders."
But within a given well defined component or module, what do we DRY up and what do we leave WET?
You are correct that DRY has nothing to do with not duplicating code blocks for the sake of not duplicating code. DRY is "Don't repeat **business rules**". For example, let's take two 2 use-cases within a payroll module:
1. Automated weekly payroll processing
2. Manual processing of a single check on employee termination.
Both use-cases need to calculate payroll taxes. We don't want to duplicate this logic, we create a PayrollCalculator component that is consumed by both use-cases. When tax laws change, we don't want to have to remember to change both. There are significant government penalties for a bug in this calculation.
For the shared "Repository" query or LINQ specification Dave is discussing...
Let's say within our inventory component we have 2 use-cases:
1. Receive stock
2. Adjust on hand quantity.
Both need to read in the item from the database and both need to update the quanitity. At first, the sql might be exact for both use-cases. Many devs exclaim "DRY!" and make a shared abstraction that does the SQL work and use it in both use-cases. A workflow change in 10 years that requires a tweak to the SQL for use-case 1 now breaks use-case 2. Let each use-case have it's own SQL. There is more harm in trying to share the SQL than writing it twice (or 3 or 4 times).
It's nuanced and more art than science. This is why AI isn't replacing Engineers. AI does't understand any of this. It will either duplicate everything, or if you tell it to use "DRY", duplicate nothing and share everything. Both extremes cause problems long term.