zlacker

[parent] [thread] 3 comments
1. nasret+(OP)[view] [source] 2024-11-11 08:02:16
Well they need to be different in _some_ way, right :)? Why not use timestamp offset for this
replies(2): >>berkes+9a >>catsma+n91
2. berkes+9a[view] [source] 2024-11-11 10:10:01
>>nasret+(OP)
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.

3. catsma+n91[view] [source] 2024-11-11 19:21:24
>>nasret+(OP)
because the extensions are already different. jpg and mp4
replies(1): >>nasret+Li1
◧◩
4. nasret+Li1[view] [source] [discussion] 2024-11-11 20:48:32
>>catsma+n91
Ok, fair point... I guess it's just that different teams were doing photo and video then
[go to top]