История изменений

А если количество отработанных часов ещё потребуется для водителей, для плановиков и для строителей, то скопипастим ещё три раза. ОК.

Их даже копировать не нужно, если тебе прилетела таска от строителя зачем тебе лезть в код бухгалтера и что то от туда копировать?

Например, сменилась структура хранения часов: теперь вместо часов на каждый день по сотруднику пишется дата начала, дата окончания, количество за период. Теперь нам надо в пяти местах сделать почти идентичный исправления. Причём делать их будут 5 команд независимо друг от друга.

Если база меняется то вероятно актор это админ, он ставит таску и в рамках этой таски ты все это делаешь, это не 5 независимых команд. Это одна таска от админа. Тут речь не о том что каждый в команде работает над своим кусочком системы, а о том как расходятся по системе изменения спровоцированные задачей от актора. Они должны расходиться так то бы не мешать другим акторам. В случае с форматом часов проблема не в том что их нужно поменять в 5 функциях, а в том что одновременно с этим бухгалтер или HR могут поставить таску на изменение формулы расчета. И если админ будет каждый день менять формат часов это эти изменения в любом случае придется как то изолировать, прятать за интерфейсом например, иначе он парализует работу с тасками от всех остальных.

Или в законе появился новый вид часов, который не сверхурочный, опять надо менять во всех 5 местах.

Нет, у тебя есть акторы, каждый из них поставит свою таску, и по этим таскам будут внесены изменения в этии 5 методов. 1 таска - 1 метод.

Если тебе как программисту явно скажут что вот это нужно считать по формуле из закона, покажут где ее брать и как следить за обновлениями, вот тогда у тебя появляется новый актор в лице правительства, который может спровоцировать изменение в твоей системе, ситуация такая же как с админом.

Кстати с сторонними библиотеками ситуация такая же, каждая библиотека подключаемая в проект это +1 актор.

Но тут еще нужно учитывать как часто эти акторы провоцируют изменения, если дба 10 лет не выходил из серверной а тут вдруг решил поменять в базе формат часов, то наверное можно и так пережить это.

просто вытащит нужные данные из БД и их не придётся тащить через, как минимум, 5 границ классов.

Что значит просто вытащит нужные данные из БД? То есть у нас была база, был модуль который собирает из базы данные и подготавливает их для вьюшек, и были сами вьюшки которые их отображают. Нам понадобились новые данные и мы прямо из вьюхи лезем в базу?

А если количество отработанных часов ещё потребуется для водителей, для плановиков и для строителей, то скопипастим ещё три раза. ОК.

Их даже копировать не нужно, если тебе прилетела таска от строителя зачем тебе лезть в код бухгалтера и что то от туда копировать?

Например, сменилась структура хранения часов: теперь вместо часов на каждый день по сотруднику пишется дата начала, дата окончания, количество за период. Теперь нам надо в пяти местах сделать почти идентичный исправления. Причём делать их будут 5 команд независимо друг от друга.

Если база меняется то вероятно актор это админ, он ставит таску и в рамках этой таски ты все это делаешь, это не 5 независимых команд. Это одна таска от админа. Тут речь не о том что каждый в команде работает над своим кусочком системы, а о том как расходятся по системе изменения спровоцированные задачей от актора. Они должны расходиться так то бы не мешать другим акторам. В случае с форматом часов проблема не в том что их нужно поменять в 5 функциях, а в том что одновременно с этим бухгалтер или HR могут поставить таску на изменение формулы расчета. И если админ будет каждый день менять формат часов это эти изменения в любом случае придется как то изолировать, прятать за интерфейсом например, иначе он парализует работу с тасками от всех остальных.

Или в законе появился новый вид часов, который не сверхурочный, опять надо менять во всех 5 местах.

Нет, у тебя есть акторы, каждый из них поставит свою таску, и по этим таскам будут внесены изменения в этии 5 методов. 1 таска - 1 метод.

Если тебе как программисту явно скажут что вот это нужно считать по формуле из закона, покажут где ее брать и как следить за обновлениями, вот тогда у тебя появляется новый актор в лице правительства, который может спровоцировать изменение в твоей системе, ситуация такая же как с админом.

Кстати с сторонними библиотеками ситуация такая же, каждая библиотека подключаемая в проект это +1 актор.

Но тут еще нужно учитывать как часто эти акторы провоцируют изменения, если дба 10 лет не выходил из серверной а тут вдруг решил поменять в базе формат часов, то наверное можно и так пережить это.

просто вытащит нужные данные из БД и их не придётся тащить через, как минимум, 5 границ классов.

Что значит просто вытащит нужные данные из БД? То есть у нас была база, был модуль который собирает из базы данные и подгатавливает их для вьюшек, и были сами вьюшки которые их отображают. Нам понадобились новые данные и мы прямо из вьюхи лезем в базу?