Подскажите как построить производство микросхем по ddd

@elisdn Спасибо

Такой вопрос - как бы вы отнеслись к тому чтобы в посте реквесте в пути запроса была бы переменная которая определяла тип процессинга ?
Тут развлекаюсь с домашками = ) и у меня есть 3 вариант как создать разные платежи (их 3 типа)
1) Для каждого типа создать отдельный эндпоинт и будет своя собственная ссылка для каждого типа в котором будет происходит валидации/создания платежа определенного типа
2) Создать один эндпоинт в дто указывать тип и внутри приложение в зависимости от этого типа выбрать стратегию по которой будет происходит создания платежа
3) Создать один эндпоинт и в path variables указывать тип а там уже дальше как в 2 подходе

а можно пример видов процессинга?

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

Всем привет!
Что вы обычно делаете, когда бизнес приходит и говорит что нужно переименовать термин предметной области.
Предположим "Node" устаревшее название, предлагается изменить на "Compute Resource".
Вытекающая проблема - это путаница и использование разной терминологии.
Т.е. нужно ли бросать все силы на рефакторинг и изменения нейминга в кодовой базе?
Или достаточно поменять только внешние интерфейсы и жить с этим.

фига се у тебя бизнес, они обычно ходят и грят "можно ли побыстрее? У нас тут тайм ту маркет" 🤔
И часто они так приходят?
можно в комментариях к классу (или что у тебя там) написать алиас
наверное зависит от того, насколько это много времени займёт. (ну если бизнес пришёл - это же задача будет, к ней будут эстимейты и вот это всё?)
Вдруг у тебя там названия классов в бд хранятся и это надо писать кучу сложных миграций
Опять же могут быть внешние приложения какие-то (по типу фронтенда или других интеграций) - там менять может быть больно
ХЗ короче, я тоже не могу выбрать обычно в таких ситуациях, на практике оставляю названия теми же чаще всего, но мы по неймингу особо не заморачиваемся

F2 в вскоде же, не?

> И часто они так приходят?
Нет, приходят не часто, но сейчас например есть одна корневая сущность в коде, нейминг которой разъехался и это реально является проблемой на мой взгляд, потому что и в коде начинают встречаться разные способы именования одного и того же и в дискуссиях.
И да, это реально больно, как вы верно упомянули, нужно менять внешние контракты API например, делать сложные миграции, депрекейтить старые поля и все вытекающие.
Для подобных ситуаций мы приняли вот такой подход: если это можно отрефакторить за приемлемые сроки(1 спринт) c минимальными рисками, то мы полностью меняем нейминг везде.
Если этого сделать невозможно, то по коду используем старый нейминг(классы, связи, методы), а во внешних контрактах и интерфейсах - новый и депрекейтим старые поля.
В общей сложности нейминг менялся 3 раза за 3 года на моей памяти и одна из сущностей до сих пор осталась в промежуточном состоянии.

фига се, так ты уже сам всё знаешь ;O

Да, наверное странный вопрос задал, просто болью поделился) Спасибо за ответ!

it depends. Если это не усложняет клиент (теперь клиенту надо следить за типом платежа) то проблемы нет. Поскольку у тебя требования к данным разные - следовательно клиенту и так придется учитывать разные типы платежек и "разные стратегии сбора данных" использовать условно.

начать с глоссария, там где можно переименовать - переименовать. Там где "не все так просто" (таблички колонки в базе репорты etc апишки) можно ввести отдельный пул элиасов терминов.

Главное убедиться что люди знают как понять что термин значит и что бы старый термин тоже был учет в глоссарии и помечен как депрекейтед. А так бросать все силы нет нужды. Путаница будет и без изменений в коде потому что людям по инерции будет сложно переключиться. Это надо постоянно людей корректировать.

Мы вот не так давно переименовывали энв и народ все еще путается, а потому в письменных обсуждениях когда нет 100% уверенности что тебя поймут просто используется New/Old term. Аля "We should allow ... for a compute resource/node". Поправлять людей на митингах и тд. Так со временем все перестроятся.

Но важно что бы был источник правды (глоссарий)

Так это домашка, решил пойти по пути 2 и если что расскажу когда я бы может быть путем 1 шел и в каких случаях - тут на самом деле it depends

В чем выражается object relational impedance mismatch?
В том, что мы много времени уделяем на написания маппинга и использование ORM?

а ты читал статью? Ну то есть, интересует уровень погружения в вопрос перед тем как пытаться тратить усилия на объяснение

p.s. если что там вся соль в концепции референсов в in merory структурах которая отсутствует в relational model что пораждает этот самый missmatch двух моделей

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

То что все объекты представляют графы и не могут быть представлены в реляционной алгебре

В том, что структура объекта может не совпадать со структурой таблиц

Поэтому приходится костылить мэппинг из таблицы в объект и обратно (ORM), чтобы их перегонять туда-сюда