Java Team Lead
  • Переходим на Java 10: проблемы и решения

    Але інформація про фізосіб і юросіб зберігається окремо.

    Итак, вы предлагаете хранить клиентов и их имена отдельно от самих клиентов. Супер. Т.е. для 3 типов клиентов имеем 4 таблицы, да? +1 тип = +1 таблица, верно? Если бы вашей таблицей пользовалась только ваша аппликуха, этот подход имеет право на жизнь.

    Но, теперь фокус — вашей таблицей пользуются 2, 3, 5, 10 других систем, которые только выбирают оттуда данные. И вместо того, чтобы выбрать из таблицы консистентные данные через SELECT * FROM Client WHERE.... в вашей схеме для получения аналогичного результата нужно будет делать какойто адский запрос. Помимо этого, вы существенно усложнили дизайн кода, введя 3 разных вложенных сущности вместо 3 полей с небольшим количество логики на них. Вот прям дизайн победы.

    Кроме того, оказалось что система Х все равно присылает вам данные о клиенте в едином формате для всех 3 типов. Бинго! Вам нужно делать мост между единым входящим форматом и своим поделием с разделением на 3 таблицы, чтобы другие системы потом, превозмогая последствия вашего архитектурного таланта, соединили что-то из 4 таблиц опять в единый формат.

    А корень вашего неверного решения в модели — попытка вынести в во вложенную ссущность то, что является целостной частью сущности, а не выделяемым фрагментом.

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

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

  • Переходим на Java 10: проблемы и решения

    Вы походу реально ментально далеки от корпоративной сферы. Я не имею желания читать вам лекцию о том, что такое клиент-ориентированность, MDM и откуда происходят те или иные корпоративные потребности. А если бы имел желание, брал бы за это деньги. Могу только посоветовать поработать в каком-нибудь истинно-кровавом ентерпрайзе с высокопрофессиональными ПМами и не сидеть на написании какихнибудь джсонов и веб ендпойнтов, а нырнуть в дизайн моделей и хранение данных. Если вас туда пустят.

    А які «шаловливые ручки» всю цю фігню туди напихали ?

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

    Чи спроектували систему так, що дозволили це зробити ?

    Прием ненормализованных и дублирующихся данных возможен и абсолютно нормален на уровне общения всей системы с внешним миром. Система должна управлять этими данными внутри. Вы не знаете елементарных вещей, погуглите хотябы что такое master data management, очевидно, что вы с этим не знакомы совершенно.

    Все ще чекаю на реальний приклад :)

    Наше по не открытое, и я не могу приводить реальные кейсы. Только общие примеры. Надеюсь, хоть что такоt коммерческая тайна, вы слышали?

  • Переходим на Java 10: проблемы и решения

    (ПІБ) у вас в основній таблиці. Тепер виявляється, що решта інформації, специфічної для фізособи — в інших.

    Во-первых, вы невнимательно читаете.
    Во-вторых, вы не мыслите абстракциями. Вы написали паспорт, поэтому ваш дизайн плох, т.к. вы даже в уме не выделили абстракцию «документ». Абстракцию «документ» может заполнять любое лицо, поэтому эти данные не являются специфическими для физ.лиц.
    В-третьих, вы совершенно не мыслите предметной областью даже в такой простой сфере как хранение клиента. Есть ФОП, который, внезапно, является юр.лицом, имея И фио И отдельно редактируемое name для которого, внезапно, конкатенация ФИО не нужна, т.к. name = ФОП «%lastName%», нежданчик? Для него тоже предложите создать отдельную таблицу?

  • Переходим на Java 10: проблемы и решения

    не треба мені про ентерпрайз-реалії розповідати

    Увы, приходится. Потому что вы явно не понимаете простых вещей.

    І чесно, ніколи не бачив

    То, что вы никогда не видели работы с сложными и большиим графами данных и так видно. Вы мыслите бизнес логикой уровня сложности Student s = new Student();. Делали ли вы дедупликацию графов данных? Я вас еще больше шокирую — внутри таблицы Client может храниться целый граф строк, связанных ссылками на одну из них. Золотые записи, слышали?

    базах з даними геологорозвідки/буріння, ні в телеком-біллінгу

    Предметная область ни о чем не говорит. Возможно, у вас было приложение из 3 таблиц с 10 полями в сумме и вся логик сводилась к тому, что поля 1, 3 и 7 должны быть нот нулл.

  • Переходим на Java 10: проблемы и решения

    адреси, контактні особи, переписка, контракти, замовлення і т.д. і.т.п.

    Все, что вы сказали, лежит в других таблицах и отделено от клиента километрами логики.

    У фізособи частини цих даних немає. Зате є інші, яких немає в юрособи — ПІБ, паспорт, ІПН, громадянство і т.д. і т.п.

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

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

    інформація про клієнта-фізособу повинна лежати в головній таблиці Client ?

    Даже в вашем вопросе содержится прямое указание на то, что у вас плохо с моделями. Перефразирую ваш же вопрос — «почему клиент хранится в таблице клиента», подумайте над этим.

    Як це випливає з бізнес-логіки ?

    Непосредственно.

  • Где доучиться?

    Косплею Владимира:
    Мне не нужен стык! Почему я должен находить на стыках? Я никому ничего не должен! Как стыки помогут мне заработать денег?
    :)

    Підтримав: anonymous
  • Переходим на Java 10: проблемы и решения

    однією таблицею для фізосіб і юросіб прокоментувати

    Т.е., вы предлагаете разнести на две таблицы таблицу, в которой 40 других полей будут идентичными, ради 3 полей с разной логикой, и которые на самом деле содержат информацию об одной и той же сущности, с разным полем type? Прям каминг-аут.

    я навіть не знаю, як цю дурню з полями на ПІБ для юрособи

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

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

  • Переходим на Java 10: проблемы и решения

    оскільки це bad design

    Bad design — это то, что вы не понимаете элементарных вещей — что есть бизнес-логика сложнее чем сущность Student(age, name) на два поля и что необходимо поддерживать консистентность соблюдая очень много условий.

    переносити це гавно в новостворену систему, яка це легасі обслуговує

    Гавно — это то, что получится у вас с таким подходом, когда вам нужно будет смоделировать сущность с 50 полями, 20 из которых — вложенные структуры, некоторые на 8 уровней глубины вложенности и несколькими тысячами строк логики, валидации, дефолтных значений, собственными исключениями, и перечнем бизнес-рулов на 15 страниц документации. Да, это ентерпрайз-реалии. Да, я понимаю что вы к ним не готовы.

    Не надо путать неспособность в сложные вещи с стремлением к хорошему дизайну.

  • Переходим на Java 10: проблемы и решения

    Але зразу таке будувати — так ми дійдемо до того, що будемо окремими полями тримати shortName, fullName i PIB — а раптом буде потрібно.

    Если надо будет — будете. И держать, и следить за соблюдением консистентности.

    Потому что есть клиентские данные, их могут быть десятки полей, сотни. И это не просто поля, они логически зависят друг от друга, иногда целыми графами. Завтра ваш клиент может стать юр.лицом, и вы введете колонку типа. И для тех, у кого тип -
    юрлицо, вы должны будете поддерживать в middleName, lastName — null, потому что у юрлица не может быть отчества и фамилии, и это в том числе отразится на вашей бизнес-логике в коде, как

    public void setMiddleName(String mN) {
    if (this.type.equals(COMPANY)) {
    throw «Company cannot have middle name»;
    }
    ....
    }

    Потому что клиент — это сложная сущность с большим количеством гипотетических состояний.

    в сеттерах прийдеться робити набагато більше.

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

  • Переходим на Java 10: проблемы и решения

    тобто в базі у вас теж чотири поля, одне з яких є об’єднанням трьох інших ?

    Да. Я думал, что это было вроде как очевидно с самого начала.

    Ок, фіг з нею, нормалізацією

    А что с ней?

    отримуємо проблеми з забезпеченням цілісності даних на рівні СУБД

    Нет.

    повинні бути дуже серйозні причини, щоб тримати в об’єкті поля, що по-суті є похідними

    Такие причины есть, и они очень серьезны. Они называются «бизнес-логика». Ах да, вы же знаете, что база, который вы управляете, может служить источником данных для других систем, да? При этом эти системы делают только рид, а алгоритмы обработки данных (читай полей-агрегаций), находятся на вашей стороне?

    ентерпрайзу і бізнес-сутностей — сумніваюсь.

    Сомнение вещь конечно благородная, но сомневаетесь вы зря.

    В целом, у меня такое впечатление, что вы представляете себе логику ентерпрайза на уровне сложности туториал-левел, там где студент-курс многие-ко-многим и три сервисных метода в пять строк типа файндСтудентБайКурс. К сожалению, ентерпрайз несколько сложнее. И далеко не всегда уютной базой вашей веб-апликухи пользуетесь только вы :)

  • Переходим на Java 10: проблемы и решения

    Чого раптом fullName став «полем в сущности»

    Потому что кто-то не читает сначала:

    Представим Client, у которого есть поля name, firstName, middleName, lastName. При этом есть логика, согласно которой name = fN + mN + lN с пробелами.

    name — персистентное поле, как и другие, кототорое всегда должно содержать в себе конактенацию трех других полей и так и храниться и сохраняться. Это сильно упрощенный кейс для примера, если шо.

  • Переходим на Java 10: проблемы и решения

    entity.fieldName

    Об это сломано много копий. Я считаю что аксессоры лучше по многим причинам. Я говорил за стиль нейминга, а не за то, чтобы выбросить аксессоры.

  • Переходим на Java 10: проблемы и решения

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

    Или мсье предлагает в сервисе

    client.setName(client.getFullName());

    ? мсье знает толк.

  • Переходим на Java 10: проблемы и решения

    Можно. Нужно ли — вопрос дискуссионный )

    На правах оффтопа и ереси :). Меня вообще раздражают геттеры как таковые на уровне конвеншна. Я принципиально не согласен с неймингом getFieldName(), поскольку гет подразумевает какое-то активное действие, а геттер чаще всего это действительно просто доступ. С моей точки зрения, гораздо лучше писать просто entity.fieldName(), потому что 1) это отражает основную суть — доступ к проперти, а не какое-то содержательное действие. 2) ощутимо визуально сокращает код и уменьшает количество словКемелКейса.

  • Переходим на Java 10: проблемы и решения

    Ооо, нажористый камент :) Бъет по наболевшему.

    Кто вам сказал, что джава ограничивается поджо? Information expert pattern слышали?

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

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

    Внезапно, оказывается, что сущность содержит внутреннюю логику, по поддержке собственного консистентного состояниия, для чего нам нужно явно контролировать, регистрировать или мутировать ее состояние на сетах. Вы хотите примеров? Их есть у меня. Представим Client, у которого есть поля name, firstName, middleName, lastName. При этом есть логика, согласно которой name = fN + mN + lN с пробелами. Вы конечно можеет сделать

    clientService.concatAllNamesIn(client)

    и засорить этим методом кучу строк в сервисе. И тем самым вы неправомерно отдадите ответственность за поддержание консистентного состояния кудато вовне, чем создадите error-prone design. А можете внедрить логику, там, где ей и место:

    private void collectNames() { ... }

    public void setFirstName(String fN) {
    this.fN = fN;
    this.collectNames(); *
    }

    * да, я знаю про нюанс с self-invocation и проксей. Но это является проблемой далеко не всегда. И на персистентных менеджед сущностях это как раз проблемой не является.

    Нездоровое стремление к поджо+сервис есть результат массового употребления спринга и хиба, которые стали аналогом золотого молотка. А как известно, если ты молоток, то все проблемы выглядят как гвозди. Поджо (с ломбоком, дада) + бездумно перегруженные логикой сервисы и боязнь выйти за эти рамки — это гвозди джавистов.

  • Где доучиться?

    нужен очень высокий IQ

    Астанавитесь ©

    Просто быть лживым, жадным и подлым — не поможет.

    Астанавитесь ©

  • Где доучиться?

    100%. Когда ты сортируешь пластиковый мусор от пищевого, ты используешь экологию. Хотя может ты и батарейки в пищевой мусор выкидываешь, не особо удивлюсь.

    Підтримали: Pavlo Svirin, Yuriy Pitometsu
  • Где доучиться?

    Как мне это поможет в бизнесе?

    Напрямую.

    Никак?

    Если бизнес по отжиманию барсеток или веб-макака, то да, никак.

    чего я помочь в общество

    Ехать лес пою? Как минимум это поможет мысли формулировать, с чем уже сейчас наблюдается проблема. Доп.эффект — откроет волшебный мир причинно-следственных связей в сфере «индивид-общество», с которыми тоже полная беда.

  • 400$

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

  • Где доучиться?

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

    А теперь он действительно верит, что земля плоская. Спрашивает, почему самолеты летают по карте не по прямой, считает что Арктика в центре диска, а Антакртида — вокруг. Всю современную космическую сферу считает ложью.

← Сtrl 1... 139140141142143...153 Ctrl →