Телеграмм чат группы oop

Да, можно. Вот я и спрашиваю где этот сервис должен быть. Это слой домена?

если по Фаулеру, то сервисный слой живёт отдельно.

17:36пожаловаться #1

SB

1. ЗАЧЕМ? Я могу просто у репозитория метод вызвать.
2. Что страшного если мусор в данных? Например, недополучит пару миллионов пока мы разбираемся что не так.

1 на случай независимости и когда не можете
2 вот не вижу что страшного если так хочется можено пойти и почистить потом.
Каким образом бизнес потеряет пару миллионов?

17:36пожаловаться #2

SB

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

просто в 90% люди хотят консистентность ради консистентности потомучто так привыкли

17:36пожаловаться #3

MG

И пусть хотят. Меньше хаоса будет

17:37пожаловаться #4

SB

1. ЗАЧЕМ? Я могу просто у репозитория метод вызвать.
2. Что страшного если мусор в данных? Например, недополучит пару миллионов пока мы разбираемся что не так.

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

Segmentation Fault in Software Design/Architecture/Zen

17:37пожаловаться #5

SF

I Scarab

если по Фаулеру, то сервисный слой живёт отдельно.

Получается в бизнес процессе "создания контракта" не будет участвовать слой доменного сервиса?

Segmentation Fault in Software Design/Architecture/Zen

17:38пожаловаться #6

SF

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

Я пожалуй буду тебя игнорировать..

17:38пожаловаться #7

SB

И пусть хотят. Меньше хаоса будет

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

I Scarab in Software Design/Architecture/Zen

17:38пожаловаться #8

IS

про консистентность... достаточно разок посмотреть на 1С с отключенной проверкой уникальности ИНН. Тысячи левых записей, многие контрагенты введены по 2-3 раза с кривыми наименованиями, паспортные данные физиков введены с ошибками и опечатками, это всё вылезает в самых неподходящих местах...
Это всё ОЧЕНЬ вредит бизнесу.

17:38пожаловаться #9

MG

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

У меня противоположный опыт. Если у вас много связей, то несоблюдение консистентности в системе только добавит вам головной боли. Автоматизация - вещь точная. Нельзя автоматизировать хаос

Segmentation Fault in Software Design/Architecture/Zen

17:40пожаловаться #10

SF

У меня противоположный опыт. Если у вас много связей, то несоблюдение консистентности в системе только добавит вам головной боли. Автоматизация - вещь точная. Нельзя автоматизировать хаос

Жаль нельзя лайки ставить

17:40пожаловаться #11

SB

I Scarab

про консистентность... достаточно разок посмотреть на 1С с отключенной проверкой уникальности ИНН. Тысячи левых записей, многие контрагенты введены по 2-3 раза с кривыми наименованиями, паспортные данные физиков введены с ошибками и опечатками, это всё вылезает в самых неподходящих местах...
Это всё ОЧЕНЬ вредит бизнесу.

eventual consustency не слышали?
это именно то что я предлагал.

Ибо к запросам к репе он не получит консистентности
во время между запросом и сохранением можно успеть удалить как бы то что мы запрашивали.

Для консистености на месте спасет только фориджен кей в базе он же констреин как я ранее писал

17:41пожаловаться #12

SB

У меня противоположный опыт. Если у вас много связей, то несоблюдение консистентности в системе только добавит вам головной боли. Автоматизация - вещь точная. Нельзя автоматизировать хаос

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

I Scarab in Software Design/Architecture/Zen

17:41пожаловаться #13

IS

eventual consustency не слышали?
это именно то что я предлагал.

Ибо к запросам к репе он не получит консистентности
во время между запросом и сохранением можно успеть удалить как бы то что мы запрашивали.

Для консистености на месте спасет только фориджен кей в базе он же констреин как я ранее писал

Это здорово в рамках какого-нибудь мелкого сайтика.
А если это распределённое бизнес-приложение и база компаний - это вообще сторонний сервис, обращение к которому ведётся через API?

17:42пожаловаться #14

SB

I Scarab

Это здорово в рамках какого-нибудь мелкого сайтика.
А если это распределённое бизнес-приложение и база компаний - это вообще сторонний сервис, обращение к которому ведётся через API?

тогда нам нужен как раз eventual consistency.
Вы просто принимаете и живете с тем что данные какое то время могут быть неконсистентны

17:43пожаловаться #15

MG

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

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

Nikita in Software Design/Architecture/Zen

17:44пожаловаться #16

N

Добрый день. Можете пожалуйста подсказать в чем отличие между DAO и Repository, и что каждый должен делать? В сети четкого ответа почему то не нашел

17:45пожаловаться #17

MG

У меня таких хендлеров 3: rest, graphql, cli. Они используют один сервис в котором есть метод для создания контракта по атрибутам. Я этот сервис и дергаю. Но это же не домен, верно?

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

17:46пожаловаться #18

SB

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

да я при чем не говорил отказыватся от консистенсности я предожил сделать ее eventual

Также преложил forigin ключи в базе на случай немедленной консистености но после этого меня вообще решили игнорировать.

Я то думал если человек не может через forigin ключ то у него система распределенная...
Но оказалось все несколько страшнее

Или вы противник eventual consistency?

Segmentation Fault in Software Design/Architecture/Zen

17:46пожаловаться #19

SF

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

Вот я спрашиваю: где с точки зрения ddd она должна происходить?