чтобы опровергнуть dry -> coupling достаточно привести хоть один пример где это не происходит (доказательство от противного) и он у многих случался когда 2 вещи вроде одинаковые и выгляди как ctrl+ c и ctrl+v со временем получали уникальное поведение
опять же и про второе не всегда верно

я думаю следующим образом srp из solid, coupling и cohesion из grasp, dry это тоже некий "принцип"
пытаться это все в одно объединить это как сову на глобус тянуть, имхо.

для меня проще рабоче крестьянское определение coupling внешние связи между модулями (пакетами и тд), cohesion внутренние и ключевое тут не строки кода а взаимодействие модулей
то что в системе может быть условно 2 пакета разных вендоров предоставляющих алгоритм uuid4 например, которые внутри могут быть форком другова пакета
для меня эта ситуация будет лишь нарушением dry и srp, а модули которые юзали uuid4 при схлопывание этих зависимостей будут иметь столько же внешних связей(coupling) такого же типа (что ничего не поменяется кроме использование другова пакета когда убираться дублирование будет)

но это мое имхо и у каждого своя истина и каждый может ошибаться

> достаточно привести хоть один пример где это не происходит (доказательство от противного)
Но если "вещи со временем получают уникальное поведение" - это не дублирование, следовательно это не случай, когда можно применять dry. Следовательно эту ситуацию нельзя использовать в доказательстве опровержения dry -> coupling
Хотя мне любопытна мысль "А что если дублирования не существует?"
> я думаю следующим образом srp из solid, coupling и cohesion из grasp
это какая-то очень ограниченная мысль, подразумевающая, что grasp и solid никак не связаны.
> coupling внешние связи между модулями (пакетами и тд), cohesion внутренние
мне кажется, что это недопустимое упрощение
И то и другое - связь.
Просто coupling - это связь с точки зрения каскадных изменений модулей. Меняю 1 модуль - надо поменять другой модуль.
Cohesion - это связь с точки зрения функциональной целостности. Группируем вместе то, у чего одна и та же цель (single responsibility из SRP)

каплинг - размазывание по проекту частей одного целого, которое должно быть инкапсулировано в одном месте, но это просто мое джуновское понимание)0

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

...получается зависимость как от библиотеки. Какой это тип каплинга не знаю )

Нет, не автоматически

Эт ты про низкий кохижен

нипанятна.
Если это дублирование - при изменении нужно будет поменять в двух модулях
Это ж каплинг?
В каких ситуациях не будет необходимости менять эти 2 модуля вместе, если есть дублирование?

А если дублирование не называть каплингом то оно перестанет быть дублированием?

Чёт вообще не понял сути разговора

Всем привет. Вопрос про планирование и наверное слишком абстрактный, но все же хотелось бы услышать мнение коллег. Есть проект, в будущем предполагает много stale данных, которые нельзя будет удалять. Навскидку развитие проекта предполагает в первые 2 года до 100тыс человек. Данных от этих людей в это время будет приблизительно насчитываться несколько гигабайт. Но потом проект обещает расти и тогда объем данных может исчилятся сотнями гигабайт или даже террабайтами. Вопрос, стоит ли сейчас учитывать этот момент при проектировании системы? Если конкретнее, то суть такова, что мне нужно Key-Value хранилище типа Etcd https://etcd.io/ с key as path, watch changes и distributed storage. Так вот по всем параметрам мне подходить именно это решение, но на их офф сайте они пишут, что reliable size примерно пару гигабайт. Этого должно хватить на первое время и затраты на разработку будут минимальные, но потом может наступить момент X, когда будут уже десятки, а то и сотни тысяч реальных пользователей, но БД уже не будет вытигявать. Так вот, стоит ли сейчас заниматься поиском другого решения, рассчитанное на масштабирование или забить на преждевременную оптимизацию и когда наступит тот момент, тогда и морочить себе голову?

Сорри за long read и спасибо заранее! Важно любое мнение 🙂

Я бы ел слона по кускам. Не факт что за 2 года не пойдет все по одному месту.

А для того чтобы проверить MVP хватит и мускуля

Через 2 года с деньгами сможете хоть с нуля новый продукт сделать. А закладываться на условный падающий метеорит - ну такое.

кликхаус

дублирование - это дублирование, а каплинг это каплинг) (несмотря на то, что я утверждаю, что дублирование всегда подразумевает каплинг)
Если дублирование - дублирование, то оно не перестанет быть дублированием
Другое дело, что есть вероятность спутать дублирование с результатом применения SRP, когда код модулей одинаковый, но причины для изменения у них будут разные.
А изначально вопрос был в том, как называется тип каплинга при дублировании кода :D

выпиши контракт для себя в виде какого-нибудь интерфейса.

а затем можно попытаться подобрать и адаптировать готовые решения.
ну и все зависит еще от самого процесса работы с данными.

будет больше записи или чтение.
если чтение , то оно только key-value или некий анализ.
сами  порции данных маленькие и их очень много или наоборот огромный snowball куда всегда только append.

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

Я сломался :D

А можно вопрос - такие мысли в голову на каком этапе приходят? Когда уже окончательно скучно кодить или есть варианты?

когда ты в отпуске и не особо понимаешь чё такое вообще каплинг и кохижен и идёшь читать книжки 70-ых 80-ых годов, чтобы самому хоть немного разобраться :D