Adding more DAX to fix problems is usually the wrong move
It starts fine:
Store Count = DISTINCTCOUNT(Facts[StoreID])
Then a fix. Then a fix for the fix. Six months later there's a comment block that starts with "DO NOT CHANGE THIS" and nobody knows why.
Totals misbehaving is almost always a relationship problem - many-to-many with no bridge table. Add the bridge and the ISINSCOPE hack goes away. Measures filtering things they shouldn't need to filter is an ETL problem - if the fact table was clean, the measure wouldn't need to know about active records or deduplication at all.
If a measure needs to figure out which visual it's in before it can calculate anything, that's the model not doing its job.
Other stuff that belongs upstream
Mixed-grain fact table - split it at ETL, not with IF(ISINSCOPE(...))
No date dimension - add one. Stop calculating date logic inside measures
Attribute in the wrong table - move it in Power Query, don't LOOKUPVALUE it at query time on every row
Aggregation that belongs at the source - pre-aggregate at the warehouse, not in a measure that recalculates on every render
Multiple versions of the same measure for different visuals - the model isn't providing consistent structure
How to spot it
- New requirements keep modifying existing measures instead of adding new ones
- A simple question needs 30 lines to answer correctly
- You can't explain what a measure does without also explaining which visual it was built for
Every workaround makes the next one harder. The person who wrote those comment blocks is gone, and now nobody knows why the overrides exist. Documentation doesn't fix that.
10 simple measures is easier to maintain for 3 years than 4 complex ones.