Читал, что такой подход считается GDPR-compliant. Но я не юрист, так что лучше проверить

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

Добрый день. Подскажите пожалуйста, второй день ломаю голову себе.
Пытаюсь сделать интернет магазин вещей с помощью DDD в качестве первого проекта.
Товары содержат всю информации: цвет (если доступен), размер.
Корзина у меня получилась агрегатом.
В корзину мы можем добавить товары, удалить, изменять его количество (уменьшать, увеличивать)
Например, где-то внутри корзины должен быть метод
class Cart {
  ....
  function editCartItemSize (CartItemId, Size) {
        cartItem = this.cartItems->get(CartItemId);
        cartItem->setSize(Size)
  }
  ...
}

Правильно ли, что мы должны через корзину редактировать внутреннюю информацию о выбранном товаре? Я согласен, что мы должны редактировать количество через корзину, но вот вся внутренняя информация - вот вопрос. Что, если будет несколько типов товаров? Допустим добавится техника, там внутренняя информация будет уже другая (допустим для телефонов - количество памяти и цвет, для процессоров - частота и модель и т.д.). В таком подходе у нас корзина разростется до больших размеров для каждого типа товара:
function editProcessorModel(CartItemId, model)
function editPhoneMemory(CartItemId, memoryId)

вот тут можно почитать, что само хранение в бэкапах, если они перезапишутся, не является нарушением: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/#ib5 . Просто необходимо будет пользователям об этом сообщить, когда последний бэкап с данными будет удалён

LoyMax (LoyMax ML)

Если не ошибаюсь, то Henrik Kniberg, тот самый, который имеет отношение к появлению Spotify Scaled Agile Mogel, что-то о фиксированном проценте на устранение техдолга писал в "Scrum and XP from the Trenches: How We Do Scrum".

Спасибо, поищу

А почему его мнение чем-то важно? А то фиксированный процент звучит очень странно.

Для планирования - не странно, руководство странно смотрит на тех.долг, дальше вопрос - кто виноват и как не допустить

Важность мнения - это субъективный фактор. Подействует ли этот аргумент на их CTO - я не знаю, но больше склоняюсь к тому, что подействует. По крайней мере, у Henric Kniberg есть успешный практический опыт в известных компаниях.

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

Странно.  Техдолг не возникает просто так. Это или плата за скорость (и тогда бюджет на техдолг нужно приписывать к задачам, которые осмысленно делали долго) или результат изменения тркбований (и тогда работа с техдолгом становится частью бюджета новых фич или отдельными проектами).
Фиксированный процент на техдолг говорит о непонимании процесса разработки и несамостоятельности команд

Я понимаю мысль, и согласен с ней.

А по поводу причин происхождения техдолга - дискуссионный вопрос. На эту тему есть статья:
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

"So is there such a thing as prudent-inadvertent debt? Although such a thing sounds odd, I believe that it is - and it's not just common but inevitable for teams that are excellent designers.

I hear this all the time from the best developers. The point is that while you're programming, you are learning. It's often the case that it can take a year of programming on a project before you understand what the best design approach should have been."

Ну и Knowledge Crunching тоже часто приводит к появлению ошибок моделирования, почему Monolith First и получил популярность.

А это и есть про изменение тркбований, то есть изменение контекста. Чистых ошибок при дизайне, которые воспринимаются как техдолг - я не встречал.

А дальше приходим к яйцо-курица-яйцо, что раньше.
Дефицитный бюджет - даст убытки, на профицитный бюджет - редкий заказчик обычно соглашается.

Прошу прощения за паузу, похоже, не привязал ответ:

По роли сложно сказать - пишу тз, архитектуру и код. Темы интересны.
Есть предвзятое отношение к IT курсам. Не понимаю, стоит ли оно своих денег. Всегда кажется, что проще открыть список тем и с гуглом выучить бесплатно.

Не совсем понял фразу.

Что первое появилось: курица или яйцо?
Так и тут, переделать архитектуру на 5ом спринте или создать тех.долг, но дать бизнесу заработать

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

> переделать архитектуру на 5ом спринте или создать тех.долг, но дать бизнесу заработать

По процессам так делать не совсем правильно. В ранних версиях Scrum и XP, действительно, качество было одной из 4-х переменной разработки. Но потом качество сделали константным и в XP, и в Scrum, поскольку обострилась борьба за контроль над этой переменной между бизнесом и технарями, из-за чего баланс интересов часто нарушался, как правило, в пользу краткосрочных бизнес-интересов, что приводило к бесконтрольному росту стоимости адаптации.

Как говорил Jeff Sutherland, бизнес должен определять "что делать", а технари - "как делать".

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

Не могли бы вы назвать эти более зрелые методики?