у меня руки не дошли пока прочитать конкретно

Плюс, как мне кажется, тесты(вместе с системой типов) в каком-то смысле описывают контракт согласно которому должен работать модуль. Если вы начинаете описывать как должны себя вести приватные методы - вы не описываете требования конкретного этого модуля, а прибиваете гвоздями специфику реализации, которой может не стать после очередного рефакторинга и тесты придется переписывать, получается оверспецификация потому что требуется то что не должно требоваться. А пока этот контракт описывает необходимый минимум можно реализацию менять как угодно не испытывая боли по поддержке тестов. Было бы интересно узнать в каких ситуациях было бы уместно объявлять методы с default доступом для тестов, учитывая что у нас есть возможность рефакторинга и код приватных методов достаточно сложный что потребовал отдельных тестов на них?

Парни, вопрос немного не по теме: вообще, если утрировать 90% существующих потребностей бизнеса, то микросервисы, по-факту, представляют собой просто удобное API к БД?

если утрировать 90% существующих потребностей бизнеса то любое приложение просто удобное api к бд или другому хранилищу

Парни, вопрос немного не по теме: вообще, если утрировать 90% существующих потребностей бизнеса, то микросервисы, по-факту, представляют собой просто удобное API к БД?

90% приложений в энтерпрайзе - это апи для БД. Микросервисы тут мало что меняют

Ну ок

Добрый день! Как программировать на Java под платформу MT4(форекс) ? никогда никакой информации я не нашел

Добрый день! Как программировать на Java под платформу MT4(форекс) ? никогда никакой информации я не нашел

Платформа — это набор аппаратно-технических решений?

Парни, вопрос немного не по теме: вообще, если утрировать 90% существующих потребностей бизнеса, то микросервисы, по-факту, представляют собой просто удобное API к БД?

API не всегда удобное.

Или какое-то ПО?

Alpha Nerd ну да это ПО, но МТ4 это как 1С Предприятие, но для форекса

Alpha Nerd ну да это ПО, но МТ4 это как 1С Предприятие, но для форекса

Берёшь API (который есть) и без задней мысли дёргаешь как тебе нужно

коба тролль

давний уже

Оу

Ну ок

Коба, нашел уже библиотечную джава сортировку по методу шелла или пузырька?

Парни, вопрос немного не по теме: вообще, если утрировать 90% существующих потребностей бизнеса, то микросервисы, по-факту, представляют собой просто удобное API к БД?

микросервисы — это не про БД

Плюс, как мне кажется, тесты(вместе с системой типов) в каком-то смысле описывают контракт согласно которому должен работать модуль. Если вы начинаете описывать как должны себя вести приватные методы - вы не описываете требования конкретного этого модуля, а прибиваете гвоздями специфику реализации, которой может не стать после очередного рефакторинга и тесты придется переписывать, получается оверспецификация потому что требуется то что не должно требоваться. А пока этот контракт описывает необходимый минимум можно реализацию менять как угодно не испытывая боли по поддержке тестов. Было бы интересно узнать в каких ситуациях было бы уместно объявлять методы с default доступом для тестов, учитывая что у нас есть возможность рефакторинга и код приватных методов достаточно сложный что потребовал отдельных тестов на них?

По моему опыту юнит тесты так и так прибиты к реализации. Особенно, когда все зависимости заменены на моки. Если говорить о более модульных тестах (тестирование компонент, интеграционные тесты, функциональные тесты), то там да - завязываться на реализацию нельзя. Нужно тестировать в black box стиле. Но тут уже вопрос о глубине тестирования и что именно тестируется.

микросервисы — это не про БД

Да понятное дело, просто архитектуру сейчас колупаю.

Да понятное дело, просто архитектуру сейчас колупаю.

кстати, зачетный ник

улыбнуло

Оксюморон же.

Да понятное дело, просто архитектуру сейчас колупаю.

ну вот непонятен контекст вопроса, напиши подробней

Парни, вопрос немного не по теме: вообще, если утрировать 90% существующих потребностей бизнеса, то микросервисы, по-факту, представляют собой просто удобное API к БД?

Раньше даже было популярно всю логику на процедурах хранить прямо в бд... Если только Апи к бд нужно, то в спринге есть сразу.

ну вот непонятен контекст вопроса, напиши подробней

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

Это примерно понятно

Просто заметил, что в куче примеров/готовых работ — каждый микросервис имеет БД на беке

Вот и складывается такое впечатление

Alpha Nerd ну да это ПО, но МТ4 это как 1С Предприятие, но для форекса

тебя же банили

а ты опять появился

тебе не надоело троллить?

коба тролль

давний уже

Просто заметил, что в куче примеров/готовых работ — каждый микросервис имеет БД на беке

как по мне, это вопрос не той категрии, в том плане, что к микросервисам не имеет отношения

как по мне, это вопрос не той категрии, в том плане, что к микросервисам не имеет отношения

М.б., это же просто диванный интерес, пока что.

1337 жирный тролль

Просто заметил, что в куче примеров/готовых работ — каждый микросервис имеет БД на беке

Ну если микросервисы разделяют одну БД, то они уже не микросервисы) это уже скорее SOA

Ну если микросервисы разделяют одну БД, то они уже не микросервисы) это уже скорее SOA

Не-не, я в том контексте, что для каждого микросервиса своя БД

задай вопрос нормально

микросервисы вообще не при чем тут

задай вопрос нормально

Не могу, ололо. КВАЛИФИКАЦИИ НЕ ХВАТАЕТ

Я же говорю — диванный интерес

Вот и складывается такое впечатление

я бы так сформулировал: 99% API над базой делаются для того, чтобы сузить API самой базы в определенный набор операций, позволяющих гарантировать целостность данных на прикладном уровне

Вопрос снят, в общем.

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

я бы так сформулировал: 99% API над базой делаются для того, чтобы сузить API самой базы в определенный набор операций, позволяющих гарантировать целостность данных на прикладном уровне

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

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

не гарантирует на самом деле

она гарантирует не на прикладном уровне

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

Как-то у меня не связывается эти 2 словосочетания - начинающий разработчик и многокластерное приложение... для начала хотябы простое приложение с тестами и с CI сделать

Это условно. Можно считать, что начинающий именно в формате многокластерной архитектуры.

Суть не в этом, вопрос остается тем же.

Это условно. Можно считать, что начинающий именно в формате многокластерной архитектуры.

ну для начала я бы разобрался с однокластерным

и это не сарказм

многокластерный?)

она гарантирует не на прикладном уровне

Можно примеры что ты имеешь ввиду?

Можно примеры что ты имеешь ввиду?

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

Можно примеры что ты имеешь ввиду?

@tairs Поправь, если неправильный кейс: Мы можем записать в БД данные, корректные с точки зрения БД, но некорректные с точки зрения бизнес-логики. Например, какое-то из полей недолжно быть нулевым с точки зрения логики, но при это нулевое значение поля допустимо в самой БД.

Можно примеры что ты имеешь ввиду?

другими словами, СУБД дает целостность логическую, например “нельзя удалять группу, если в этой группе сидит хотя бы 1 человек”, но на прикладном уровне ограничения “нельзя удалять группу, даже если она пустая, пока это не подтвердили сотрудники такой-то должности”

это конечно можно как-то закодировать средствами базы, но это оверкил КМК

@tairs Поправь, если неправильный кейс: Мы можем записать в БД данные, корректные с точки зрения БД, но некорректные с точки зрения бизнес-логики. Например, какое-то из полей недолжно быть нулевым с точки зрения логики, но при это нулевое значение поля допустимо в самой БД.

тогда бд неправильно спроектировано

тк констрэйнты ставят по требованиям бизнеса

ERROR: S client not available

другими словами, СУБД дает целостность логическую, например “нельзя удалять группу, если в этой группе сидит хотя бы 1 человек”, но на прикладном уровне ограничения “нельзя удалять группу, даже если она пустая, пока это не подтвердили сотрудники такой-то должности”

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

тогда бд неправильно спроектировано

Ну понятно, что при создании БД это учитывается, просто как пример же.

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

средствами БД много чего можно делать, но я бы не стал

ну для начала я бы разобрался с однокластерным

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

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

CAP-теорема, протоколы консенсуса, задача о полководцах

Спс.

Спс.

Модели консистентности еще

средствами БД много чего можно делать, но я бы не стал

Ну как раз контроль за целостностью данных надо делать в БД, раз уж взяли что-то реляционное, а не монгу

Ну как раз контроль за целостностью данных надо делать в БД, раз уж взяли что-то реляционное, а не монгу

а если данные о должностях лежат в табличке в гуглдоксе?

а если данные о должностях лежат в табличке в гуглдоксе?

или дергать из Постгреса хттп?

а если данные о должностях лежат в табличке в гуглдоксе?

а роли пользователей в системе написаны где-то на бумажке?

а роли пользователей в системе написаны где-то на бумажке?

это все к тому, что в жизни не все “красиво по учебнику”, данные могут быть разнесены в разные хранилища, и API поверх хранилищ решает эти вопросы

Ну типа если данные не нормализованы, а бизнес-процессы не формализованы, ни одна система тебе не сможет гарантировать надежность

Ну типа если данные не нормализованы, а бизнес-процессы не формализованы, ни одна система тебе не сможет гарантировать надежность

не об этом речь

Реализуя бизнес-логику на стороне БД, вы жестко привязываетесь к СУБД

СУБД вам могут гарантировать целостность данных прикладного уровня, но для этого все данные должны лежать в одной базе, то бишь монолит, но в жизни такое не часто бывает

чаще данные размазаны по разным хранилищам

Реализуя бизнес-логику на стороне БД, вы жестко привязываетесь к СУБД

ИМХО, это часто надуманная проблема

Бывают приложения, которым БД не особо нужно. У нас например чисто stateless processing.

БД чисто для отлова ошибок

Ребята, всем привет. Подскажите что происходит... Создал проект на спрингбут кидаю запрос - ничего. Запустил старый проект - запросы летят нормально. Весь каркас идентичный, все нужные аннотации стоят на своих местах. Психанул создал новый проект, полностью скопировал весь код с сайта спринга, добавил туда свой код который не хотел ловиться и вуаля все полетело. Что я делал не так?

ИМХО, это часто надуманная проблема

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

Бывают приложения, которым БД не особо нужно. У нас например чисто stateless processing.

Часто вы такое наблюдаете?

А не так вопрос понял)

Часто вы такое наблюдаете?

Я к тому, что не все на БД завязано.

В любом случае логика на уровне бд это немного не ок имхо

В любом случае логика на уровне бд это немного не ок имхо

Не говоря о том, что писать на всяких Pl/PgSQL можно только основательно набравшись или имея два магистра

Бывают приложения, которым БД не особо нужно. У нас например чисто stateless processing.

Ну изначально речь шла о 90%. Ваш случай, очевидно, сюда не попал

Ну тут вопрос - что считать логикой

UniqueConstraint - это логика?

Тригеры и хранимки полезны для решения других проблем, например логи изменений