Если прикладной слой одного сервиса не общается на уровне orm или непосредственно на уровне СУБД к сущностям в бд, которые относятся к предметной области другого сервиса, а в свою очередь использует выделенные высокоуровневые интерфейсы, то изоляция соблюдается.
Это позволяет экономить ктс, но в таком случае отказы не изолируются, т.к. некоторые параметры СУБД работают на все схемы и не могут быть дифференцированы по схемам, следовательно, возникает некая технологическая связанность.
Можно гипотетический делать много микросервисов которые работают с одним хранилищем. Однако в таком подходе могут возникать ситуации, когда разработчик сервиса альфа решает через свой сервис изменять данные, которые относятся к другой команде и другому сервису, например Бетта.
Таким образом на уровне хранения возникает связь бетта-альфа. В дальнейшем если будет принято решение например о шардировании хранилища, ранее реализованная связь усложнит шардирование, кроме того данная связь не будет горизонтально масштабируемой.
Поле расход доход свернуть в одно можно. Добавить вид операции, дальше по видам операции можно суммировать какие-то агрегаты по категориям.
Можно добавить в разметку таблицы транзакций ещё что-то вроде бюджетных аналитик, например место возникновения затрат (ребенок 1), ЦФО (мама).
Добавить отдельно таблицу резервирования бюджета в разрезе мвз-цфо, при создании записи в таблице фактов проверять по бюджетным аналитикам пролазит или нет в текущий резерв.
Как мне кажется категоричные суждения часто приводят к неверным решением. В данном случае строгий запрет на реализацию синхронных взаимодействий может привести к множеству оверхедов.
Всё-таки применение практик должно основываться на конкретной ситуации, а посыл "не делайте никогда" делает его независимым от контекста ситуации.
А по факту понять хороший или плохой API можно только опытным путем. Т.е. ретроспективно мы оцениваем реализацию и говорим - кажется это хорошая штука. Потому что определять "хорошесть" будут клиенты, которых на этапе проектирования может и не быть.
Там в итоге одно за одно цепляется. В итоге и в складе сага нежелательна, а какая-то двухфазная фиксация - потому что вокруг склада какие-то процессы тоже есть. Это и проверка доступности и планирование закупок исходя из этого, и бюджетирование.
Чтобы эти лоукод бпмс системы работали в реальной жизни, на мой взгляд нужно, чтобы эти сами процессы были описанные и соответствующие реальности, что случается кстати случается довольно редко.
Ну и ещё - кажется, что рано или поздно любая бпмс в формате лоукод приходит к тому, что у шагах модели начинают появляться достаточно сложные скрипты. Поэтому питать иллюзий не стоит, большое преимущество у бпмс - это наглядность процесса для суппорта и предварительно обследование самого бизнеса, а остальное уже скорее приятные ништяки.
Ну вот общество подумало-подумало и решило, что ЕГЭ хорошо проверят так называемый "СОЦИАЛИЗИРУЮЩИЙ МИНИМУМ". Общегосударственный выпускной экзамен - это не какая-то сугубо российская придумка.
На мой взгляд скорее ваше представление о социализирующем минимуме не совпадает с представлением общества об этот минимуме.
Система в Сбере соответствует общепринятой в целом в трудовой сфере в России, а общепринятая в разработке ПО не соответствует общепринятой в трудовой сфере. Истоки этого расхождения кроются в старинных квалификационных справочниках.
А что такое вообще историчность проводки? Ну то есть какой бизнес-атрибут проводки может быть изменён во времени, который требует историчности? Кроме например какой-то реверсивной проводки.
Маловероятно, что образование существенно влияет на рождаемость. Ответа на вопрос о причинах низкой рождаемости после второго дем перехода в общем-то нету. Уже очень много факторов рассматривали. На мой взгляд основной всё-таки это поздний выход на уровень дохода, который позволяет иметь семью в развитых странах. То есть например как в Японии или США когда съезжают от родителей в 30+ лет, и речь не только о переезде, но и в целом о карьерном росте.
Много статей на японском на эту тему, рекомендую ознакомиться. Нам следует следить за Японией как самой передовой страной на этом фронте. Второй пример это Франция, который удалось поднять рождаемость в т.ч. за счёт мигрантов.
Любой управленческий учёт базируется на бухгалтерском факте. Вы конечно можете например вести какое-то сальдо по счету без аналитической разбивки, но в конечном итоге у вас даже с управленческой разметкой данных итог должен замэпится на сальдо.
Бухгалтерия появилась не от государства, и нужна она не только ему, а в стейкхолдерам.
Как раз обычно бухгалтерский и налоговый учёт выделают в отдельные блоки
Как правило достоверный экономический эффект по подобным проектам очень сложно посчитать, на моей практики пше/трудозатраты чаще всего выдумываются, т.к. чтобы рассчитать эффект реально, нужно хорошо таймшитировать трудозатраты
Так они его и не будут блокировать, речь о том что в случае если сервер будет идти сразу же до ресурса-чекера, то адрес будет сразу раскрыт.
Так можно достаточно много серверов перебанить, конечно кроме ситуации когда маршрутизация правильно настроена
Да, только ошибка обычно дороже выходит у всех этих персонажей. Погромистов же обычно редко выпускают на боевой стенд.
А так да, вот бы была песочница где руку в плиткорезанье или укладке набить
Если прикладной слой одного сервиса не общается на уровне orm или непосредственно на уровне СУБД к сущностям в бд, которые относятся к предметной области другого сервиса, а в свою очередь использует выделенные высокоуровневые интерфейсы, то изоляция соблюдается.
Это позволяет экономить ктс, но в таком случае отказы не изолируются, т.к. некоторые параметры СУБД работают на все схемы и не могут быть дифференцированы по схемам, следовательно, возникает некая технологическая связанность.
Почти все в статье работает из коробки в SAP...
Одна СУБД на несколько сервисов - это необязательно монолитная архитектура.
Можно гипотетический делать много микросервисов которые работают с одним хранилищем. Однако в таком подходе могут возникать ситуации, когда разработчик сервиса альфа решает через свой сервис изменять данные, которые относятся к другой команде и другому сервису, например Бетта.
Таким образом на уровне хранения возникает связь бетта-альфа. В дальнейшем если будет принято решение например о шардировании хранилища, ранее реализованная связь усложнит шардирование, кроме того данная связь не будет горизонтально масштабируемой.
Я так вижу эту ситуацию.
Крупные конторы редко сидят на 1с
Поле расход доход свернуть в одно можно. Добавить вид операции, дальше по видам операции можно суммировать какие-то агрегаты по категориям.
Можно добавить в разметку таблицы транзакций ещё что-то вроде бюджетных аналитик, например место возникновения затрат (ребенок 1), ЦФО (мама).
Добавить отдельно таблицу резервирования бюджета в разрезе мвз-цфо, при создании записи в таблице фактов проверять по бюджетным аналитикам пролазит или нет в текущий резерв.
Но это на правах шизофрении
Как мне кажется категоричные суждения часто приводят к неверным решением. В данном случае строгий запрет на реализацию синхронных взаимодействий может привести к множеству оверхедов.
Всё-таки применение практик должно основываться на конкретной ситуации, а посыл "не делайте никогда" делает его независимым от контекста ситуации.
А по факту понять хороший или плохой API можно только опытным путем. Т.е. ретроспективно мы оцениваем реализацию и говорим - кажется это хорошая штука. Потому что определять "хорошесть" будут клиенты, которых на этапе проектирования может и не быть.
Там в итоге одно за одно цепляется. В итоге и в складе сага нежелательна, а какая-то двухфазная фиксация - потому что вокруг склада какие-то процессы тоже есть. Это и проверка доступности и планирование закупок исходя из этого, и бюджетирование.
Везде по итогу все по-разному
Чтобы эти лоукод бпмс системы работали в реальной жизни, на мой взгляд нужно, чтобы эти сами процессы были описанные и соответствующие реальности, что случается кстати случается довольно редко.
Ну и ещё - кажется, что рано или поздно любая бпмс в формате лоукод приходит к тому, что у шагах модели начинают появляться достаточно сложные скрипты. Поэтому питать иллюзий не стоит, большое преимущество у бпмс - это наглядность процесса для суппорта и предварительно обследование самого бизнеса, а остальное уже скорее приятные ништяки.
Ну вот общество подумало-подумало и решило, что ЕГЭ хорошо проверят так называемый "СОЦИАЛИЗИРУЮЩИЙ МИНИМУМ". Общегосударственный выпускной экзамен - это не какая-то сугубо российская придумка.
На мой взгляд скорее ваше представление о социализирующем минимуме не совпадает с представлением общества об этот минимуме.
Да просто если хотя бы раз в жизни видел эксел
Скорее так:
Система в Сбере соответствует общепринятой в целом в трудовой сфере в России, а общепринятая в разработке ПО не соответствует общепринятой в трудовой сфере. Истоки этого расхождения кроются в старинных квалификационных справочниках.
Кажется, что всё-таки связано в первую очередь не с неймингом, а с особенностью работы с оргштатной структурой.
А что такое вообще историчность проводки? Ну то есть какой бизнес-атрибут проводки может быть изменён во времени, который требует историчности? Кроме например какой-то реверсивной проводки.
Маловероятно, что образование существенно влияет на рождаемость. Ответа на вопрос о причинах низкой рождаемости после второго дем перехода в общем-то нету. Уже очень много факторов рассматривали. На мой взгляд основной всё-таки это поздний выход на уровень дохода, который позволяет иметь семью в развитых странах. То есть например как в Японии или США когда съезжают от родителей в 30+ лет, и речь не только о переезде, но и в целом о карьерном росте.
Много статей на японском на эту тему, рекомендую ознакомиться. Нам следует следить за Японией как самой передовой страной на этом фронте. Второй пример это Франция, который удалось поднять рождаемость в т.ч. за счёт мигрантов.
Любой управленческий учёт базируется на бухгалтерском факте. Вы конечно можете например вести какое-то сальдо по счету без аналитической разбивки, но в конечном итоге у вас даже с управленческой разметкой данных итог должен замэпится на сальдо.
Бухгалтерия появилась не от государства, и нужна она не только ему, а в стейкхолдерам.
Как раз обычно бухгалтерский и налоговый учёт выделают в отдельные блоки
Вы удивитесь, но есть аддоны по типу xltools, которые позволяют работать через sql/подобие sql с таблицами в excel
Как правило достоверный экономический эффект по подобным проектам очень сложно посчитать, на моей практики пше/трудозатраты чаще всего выдумываются, т.к. чтобы рассчитать эффект реально, нужно хорошо таймшитировать трудозатраты