потому я репозитории те же рядом с сущностями кладу, ибо мне так удобнее

прям реализации репозиториев?

прям да

прям даже не делаю интерфейсы)

потому что всеравно реализация репозитория под сущность одна единственная

ну не делать интерфейсы - это норм :)

надо будет - сделать легко. но рядом класть... такое :)

одно - из домена. другое - из инфраструктуры

меня парит, что получается User и User две разных сущности (DO и DS объекты). Допустимо ли ту модель, которая к базе ближе именовать UserRow, например?

меня парит, что получается User и User две разных сущности (DO и DS объекты). Допустимо ли ту модель, которая к базе ближе именовать UserRow, например?

а другая модель,та которая дальше от базы - это что?

DO

чтотакое do? domainobject? а в чем разница?

у меня почемуто сразу домен обьекты выдает ORM

да, domain object я задумался. я не работал с ORM — может оно и является репозиторием для DO? в базе будет храниться сильно меньше полей, чем нужно в рантайме разве нет правила, по которому один тип объекта только на смежных слоях/уровнях используется? если буду её тянуть с уровня DS то она через три уровня пройдёт как я понимаю, тот User, что лежит рядом со Storage и является моделью, нужен только для того, чтобы сохранить/достать «Домееного» юзера из базы и не должен с ним особо пересекаться. но я могу и ошибаться

т.е. у базы — это просто POJO строка из базы. а в домене — уже с логикой

в ОРМ просто описывается маппинг, строки и релейшенов там.. на доменные обьекты. и оно само из базы готовит нам обьект. и сохраняет правильно.

ну, получается, там не нужны «низкоуровневые» классы — DAO и модель к нему и, наверное, не нужен репозиторий. а если ORM нет, как у меня, тогда оно начинает быть нужно

Забудь про слои и просто скинь все в одну папку, будет лучше на старте, чем наличие ненужных "слоев"

это уже не старт, это попытка сделать из «папки» более удобную структуру (вместе с усложнением проекта)

одно - из домена. другое - из инфраструктуры

и в чем проблема если оно отделено друг от друга?)

это уже не старт, это попытка сделать из «папки» более удобную структуру (вместе с усложнением проекта)

Когда дойдет до контекстов и разбиение реально понадобится - разобьешь

Привет коллеги! Разсудите пожалуйста. Разрабатываю архитектуру модуля мониторинга автотранспорта и сотрудников для ERP системы. Всё как обычно: жпс-трекеры, приложения на смартфонах - передают данные на сервер, где они хранятся. Необходимо в будущем строить отчеты по пробегу автомобилей, формировать путевые листы по каждому автомобилю, необходимо также иметь оперативную информацию о местоположению автомобилей, сотрудников и другой мониторируемой техники. Вопрос вот в чем. Я раньше всегда в подобных случаях хранил гео-данные с ЖПС-трекеров с привязкой к этим трекерам (т.е. трекерИД, геоточка, скорость и т.д.), но сейчас меня осенило, что это, возможно, неверный подход и я пытаюсь протащить новую идею - хранить гео-данные с привязкой к конкретному объекту наблюдения. Это позволит, например, менять жпс-трекеры на автомобиле (в случае поломки трекера, например) и при этом проодлжать собирать информацию в разрезе того же автомобиля. Мои коллеги, привыкшие к хранению гео-данных в разрезе трекеров, пока что очень сопротивляются дмнному решению. Хотелось бы узнать мнение сообщества по этому поводу: 1. Хранить гео-данные относительно трекеров? или 2. Хранить гео-данные относительно объектов наблюдения?

Ты в любом случае снимаешь данные с трекеров и привязываешь их к объектам наблюдения. Т.е. можно сделать реляцию Объект наблюдения -> one 2 many -> Трекер -> one 2 many -> гео-данные

Можно выкинуть из этой схемы трекер, но суть не поменяется.

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

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

То, о чем я говорю - это уход от понятия "трекер" вообще. Предполагается, что не важно, каким способом были получены гео-данные: или трекером №1 или трекером №25 - они при получении будут привязаны сразу же к наблюдаемому объекту. То есть данные будут храниться не для каждого трекера, а для каждого, скажем, автомобиля

тогда конечно лучше денормализовывать данные

то есть хранить и для трекера и для автомобиля одновременно?

можно простодобавить денормализованное поле. object_id для гео-данных

всего одно

трекер как устройство в принципе не должно иметь отношения к данным трекинга автомобиля

хотя у вас же постгря, там можно через оконные функции все спокойно посчитать. Оптимизатор справится с такой задачей на ура)

но это имхо в общем - да, я бы убрал привязку к трекеру

можно простодобавить денормализованное поле. object_id для гео-данных

вот я, кстати, об этом тоже думал. добавить поле, чтобы и трекер_ид и объект_ид писать для каждой гео-позиции

трекер как устройство в принципе не должно иметь отношения к данным трекинга автомобиля

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

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

хотя у вас же постгря, там можно через оконные функции все спокойно посчитать. Оптимизатор справится с такой задачей на ура)

зачем усложнять? :)

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

зачем усложнять? :)

аналитические функции и существуют для таких задач

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

но конкретные геоданные относятся к машине, а не к трекеру

аналитические функции и существуют для таких задач

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

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

это само собой. вопрос не в этом

но конкретные геоданные относятся к машине, а не к трекеру

! вот !

?

object_id, tracker_id, long, lat, date и норм)

по этой таблице можно будет отследить время смены оборудования, если надо

То есть идея, в общем-то, верная. Трекеры - всего лишь инструменты для получения информации о местоположении объекта. Нам нужно учитывать эти инстурменты только со стороны учета их движения в системе, как товаров (ТМЦ), но не хранить их историю местоположений. А информация, измеренная этими инстурментами, относится непосредственно к тем объектам, которые измеряются.

object_id, tracker_id, long, lat, date и норм)

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

Спасибо! Теперь я спокоен :)

Привет коллеги! Разсудите пожалуйста. Разрабатываю архитектуру модуля мониторинга автотранспорта и сотрудников для ERP системы. Всё как обычно: жпс-трекеры, приложения на смартфонах - передают данные на сервер, где они хранятся. Необходимо в будущем строить отчеты по пробегу автомобилей, формировать путевые листы по каждому автомобилю, необходимо также иметь оперативную информацию о местоположению автомобилей, сотрудников и другой мониторируемой техники. Вопрос вот в чем. Я раньше всегда в подобных случаях хранил гео-данные с ЖПС-трекеров с привязкой к этим трекерам (т.е. трекерИД, геоточка, скорость и т.д.), но сейчас меня осенило, что это, возможно, неверный подход и я пытаюсь протащить новую идею - хранить гео-данные с привязкой к конкретному объекту наблюдения. Это позволит, например, менять жпс-трекеры на автомобиле (в случае поломки трекера, например) и при этом проодлжать собирать информацию в разрезе того же автомобиля. Мои коллеги, привыкшие к хранению гео-данных в разрезе трекеров, пока что очень сопротивляются дмнному решению. Хотелось бы узнать мнение сообщества по этому поводу: 1. Хранить гео-данные относительно трекеров? или 2. Хранить гео-данные относительно объектов наблюдения?

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

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

"приходит инфа какая машина сейчас используется." - в каком смысле?

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

с геоданными ИД трекера нет. трекер "не знает" где он установлен. зачем ему это

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

трекер подключается к серверу и авторизуется. сервер (модуль системы) запрашивает у ядра, можно ли этому трекеру авторизиваться. Если трекер привязан к автомобилю, то дается разрешение в сторону сервера и сервер подтверждает авторизацию. Вместе с этим разрешением в сторону сервера ядро может передать что угодно. Так что нет проблемы передать ИД автомобиля в модуль и далее использовать миенно его.

Единственная проблема, которая может возникнуть при такой схеме. И то, я не уверен, что она действительно существует. Это сбор данных об уровне топлива. Трекеры требуют калибровки датчиков. Если трекер поменяли, то необходимо произвести перекалибровку. Но это проблема более надуманная, чем реальная, потому что мы пока что не используем информацию об уровне топлива и пока, вроде как, не планируем.

Тут уже кажется было такое. Скажите, а нужен ли эксепшенам постфикс Exception?

И если не нужен, то почему

Тут уже кажется было такое. Скажите, а нужен ли эксепшенам постфикс Exception?

SomethingFailed -не нужно

InvalidArgumentException - нужно

а не

там тоже можно опустить

ERROR: S client not available

И получается каша

Я добавляю. Ну в контраргумент обычно приводят, то что по имени исключения и так должно быть понятно что произола неприятность типо ServiceNotFound, StorageWasFull

А если у меня есть ServiceException, который является родителем для ряда других эксепшенов

кароч я лояльно отношусь к суффиксу Exception

InvalidArgumentException - нужно

это хреновое название)

InvalidArgumetnWasPassed

))

на самом деле я добавляю суффикс экспшн чтобы отличать экспшны от евентов

больше я не вижу пользы

c *Exception как то больше понятно что происходит

c *Exception как то больше понятно что происходит

а слово throw разве недостатчоно для понимания?

Эксепшены не нужны /thread

А если у меня есть ServiceException, который является родителем для ряда других эксепшенов

который сам по себе не говорит о какой-то конкретной ошибке, нельзя же его просто Service назваьт

Разве что ServiceError, но это шило на мыло

Главное делать однообразно) с суффиксом или без, но не когда часть с суффиксом и часть без))

который сам по себе не говорит о какой-то конкретной ошибке, нельзя же его просто Service назваьт

так ServiceException эт тоже херня какая то

ошибка службы

я под это определение любую могу подогнать ситуацию

пойду поем

Эксепшены не нужны /thread

нужны, увы

по крайней мере в языке на котором я работаю точно

это прям 100%

я под это определение любую могу подогнать ситуацию

Именно так оно и работает

Разве что ServiceError, но это шило на мыло

YourBoundedContextNamespace/Exception - базовый

это родитель для множества эксепшенов

Зачем базовому какой-то префикс

И получается каша

нет

Да, половина с постфиксом, половина без

)

половина методов приватная половина публичная

каша какая-то