While this comment is a joke, it's tragicomically true as well.
Way too often have I encountered, or hacked in myself, such "business rules".
"Except for these seven transactions from before [random date/time] all transactions made between 01:00 and 01:15, with a round amount, are recurring payments to X. Can we not just use that instead of this data-migration that you've budgetted?" (not literal request, but close enough).
The danger -off course- lies in that this over time becomes actual business logic and that meaning is assigned to (meta)data that was never intended to carry such meaning.
The solution -I've found- starts with what DDD calls "ubiquitous language", where everyone (within a domain!) assigns the same meaning to the same things¹. And model the software around that, never the other way.
¹ So maybe there's a 150 year old rule that states that recurring transactions are those that happen between ...etc. etc. That this is actually a settled and used meaning within the domain experts/users/stakeholders. In that case - IMO - it's far better to lean into it rather than assign some is_recurring_for_x boolean or such that has no meaning in the domain.
Programming employment-creation measure - to prevent them doing damage elsewhere by adding abstraction madhouses.
Well they need to be different in _some_ way, right :)? Why not use timestamp offset for this
While this comment is a joke, it's tragicomically true as well.
Way too often have I encountered, or hacked in myself, such "business rules".
"Except for these seven transactions from before [random date/time] all transactions made between 01:00 and 01:15, with a round amount, are recurring payments to X. Can we not just use that instead of this data-migration that you've budgetted?" (not literal request, but close enough).
The danger -off course- lies in that this over time becomes actual business logic and that meaning is assigned to (meta)data that was never intended to carry such meaning.
The solution -I've found- starts with what DDD calls "ubiquitous language", where everyone (within a domain!) assigns the same meaning to the same things¹. And model the software around that, never the other way.
¹ So maybe there's a 150 year old rule that states that recurring transactions are those that happen between ...etc. etc. That this is actually a settled and used meaning within the domain experts/users/stakeholders. In that case - IMO - it's far better to lean into it rather than assign some is_recurring_for_x boolean or such that has no meaning in the domain.
because the extensions are already different. jpg and mp4
Ok, fair point... I guess it's just that different teams were doing photo and video then