NF
Проблема в ЯП: в ТС только дак-тайпинги есть - так что это то же самое будет
женерики и тегирование твой друг)
Size: a a a
2020 October 26
SP
ну вы сча уже за контроль над этим всем со стороны компилятора, достаточно просто немного семантики добавить
NF
type OrderId = string & { _type: "OrderId" }˸A
женерики и тегирование твой друг)
Вот не надо, а? У меня все айдишники - стринги. Зачем мне ещё что-то?
SP
мне нравится аналогия - попробуйте мол взять ваш код и быстро ответить че делает ваша система. Натравите мол облако тегов из кода и посмотрите какие кейворды есть. Вдруг окажется что ваша сложная распределенная система "чет делает со строками и числами"?)
˸A
мне нравится аналогия - попробуйте мол взять ваш код и быстро ответить че делает ваша система. Натравите мол облако тегов из кода и посмотрите какие кейворды есть. Вдруг окажется что ваша сложная распределенная система "чет делает со строками и числами"?)
Базовые типы никто не отменял. Где-то всё равно они будут - в любой либе
NF
хотел сказать "ты беседуешь с двумя по колено фронтендерами, которые пишут однопоточное приложение с формочками", но вспомнил что однопоточные веб приложения с формочками тоже распределенная система, просто многие про это забывают
NF
я просто в раздумьях на каком уровне это надо соблюдать. Вот есть у тебя два отдела - одни продают штуки другие их используют. И у тех и у других много терминов пересекаются но значат разные вещи. Заканчивается ли действие UL на уровне контекста и дальше лучше не пытаться "делать общие термины" и достаточно лишь для каждого контекста свой глоссарий сделать?
есть же такая штука для синка данных больших систем где у тебя явно прописываются все имена и мапинги с неймспейсами, типа fhir только не для медицины
NF
rdf там всякие, семантические технологии, вот это все
NF
по сути тот же единый язык для обмена данными, ну единый по крайней мере в рамках организации, а дальше есть мапинги одного на другое
NF
я поясню свою мысль пожалуй - я часто вижу попытки унифицировать терминологии и эти попыки часто фэйлятся ибо разным людям в целом насрать какие термины используют их коллеги в других контекстах
так что есть даже не попытки, есть успешные реализации, в том же сбербанке
NF
(не работал в сбербанке, доклады их смотрел про то как они это вводили)
АГ
я просто в раздумьях на каком уровне это надо соблюдать. Вот есть у тебя два отдела - одни продают штуки другие их используют. И у тех и у других много терминов пересекаются но значат разные вещи. Заканчивается ли действие UL на уровне контекста и дальше лучше не пытаться "делать общие термины" и достаточно лишь для каждого контекста свой глоссарий сделать?
любая работа ведется в контексте какой-то задачи, вот в рамках этого контекста и надо выстраивать язык, разве нет?
АГ
единый язык - продукт совместной работы людей над проектом. когда туда придет новый человек, неизбежно будут проблемы взаимопонимания.
АГ
люди очень любят выдумывать термины, жонглировать ими и выглядеть умными)
АГ
складывается чувство, что задачи "сказать так, чтобы тебя поняли" нет, но есть наоборот, задача сказать так, чтобы тебя не поняли, но ты показался бы умным и квалифицированным)
NF
единый язык - продукт совместной работы людей над проектом. когда туда придет новый человек, неизбежно будут проблемы взаимопонимания.
думаю речь идет как раз о ситуации когда на проекте над доменом работает несколько команд и у них нет совместной работы и даже одной кодовой базы, и возможно даже коммуникаций
АГ
стандарты и документация - хорошая вещь. для этого мы и учимся, чтобы разговаривать на некотором принятом в том или ином обществе языке.
АГ
например - "отношение" - это таблица. вот живи с этим теперь.
DT
люди очень любят выдумывать термины, жонглировать ими и выглядеть умными)
Это вершина айсберга. Чаще обычный термин, который понятен всем, используется для разных вещей в одном контексте. С таким не раз сталкивался