Size: a a a

Архитектура ИТ-решений

2021 February 28

AM

Alexey Mergasov in Архитектура ИТ-решений
Речь изначально шла о примере функционального анализа из физтеха.
источник

S

Sdobridnuk in Архитектура ИТ-решений
Alexei, начнём с того что 'платёжное распоряжение' отсутствует как бланковый документ. Есть платёжное поручение, а есть платёжное требование. Соответственно сущность  платёжное распоряжение выводится из государственной нормативки и правил в область частной деловой практики. И соответственно что есть результат его исполнения, хз. Может спинку мылом клиенту надо потереть, когда клиент его предъявить? :) обсуждать терминологии и автоматизировать кастом, дело неблагодарное, хотя и забавное для любителей поговорить..
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Gennadiy Kruglov
Артефакты анализа удобно отражать на конструкции ЯП естественным образом, а не через костыли (классы)
Я согласен, что в ООП сделали странное. Я бы описал это так: придумали новую мощную абстракцию (класса и объекта, а позже - интерфейса), а потом зачем-то все, что было наработано ранне и было вполне себе хорошо - начали представлять как классы и объекты. Объект "5", метод "add" и т.п. По-моему тоже просто некоторые задачи/решения по своему характеру проще мыслятся на обычном процедурном языке или на чистом функциональном языке, а другие классы задач/решений - легче выражаются на ООП (там, где состояние имеет значение, с какими-нибудь стеками, например). ИМХО, будущее не за шовинистическими, а за плюралистическими языками, где есть и то, и то, и бери, что тебе удобнее в данном месте (скажем, F#). Ну, правда, с моей т.з. у мейнстримных ОО ЯП есть несколько детских дефектов, мешающих инкапсуляции сложности... ФП именно в этих местах зачастую выигрывает, и вовсе не за счет того, что в ФП не работают с состоянием, а, например, за счет того, что строго блюдутся границы и нет всяких "static", которые суть скрытые глобалы.
источник

A

Anatoly in Архитектура ИТ-решений
лол. раньше думал, что я графоман. да я даже рядом не стоял!
источник

S

Sdobridnuk in Архитектура ИТ-решений
Проводка со счета на счёт может быть просто записью. Вы для каждого insert в SQL будете функции дефинировать?
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Sdobridnuk
Alexei, начнём с того что 'платёжное распоряжение' отсутствует как бланковый документ. Есть платёжное поручение, а есть платёжное требование. Соответственно сущность  платёжное распоряжение выводится из государственной нормативки и правил в область частной деловой практики. И соответственно что есть результат его исполнения, хз. Может спинку мылом клиенту надо потереть, когда клиент его предъявить? :) обсуждать терминологии и автоматизировать кастом, дело неблагодарное, хотя и забавное для любителей поговорить..
Ед101 альбом уфебс цб рф. Никто ничего выводить не собирается. В iso есть аналоги.
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Gennadiy Kruglov
Артефакты анализа удобно отражать на конструкции ЯП естественным образом, а не через костыли (классы)
Кстати, в эту тему может быть интересно посмотреть, что сделали в Julia с "множественной диспетчеризацией" вызова функций по имени. Это как раз для расчетных задач лучше всего работает.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Igor Bespalchuk
Кстати, в эту тему может быть интересно посмотреть, что сделали в Julia с "множественной диспетчеризацией" вызова функций по имени. Это как раз для расчетных задач лучше всего работает.
Меня больше приземлённые вещи интересуют сейчас
источник

S

Sdobridnuk in Архитектура ИТ-решений
ООП, и Яву лишь язык выражения требований. И явно зависит от 'тупости' исполняющий системы. Когда то ей надо было давать инструкции в машинных кодах, потом на ассемблере, потом на ЯВУ. Но это все императивные языки для машины тьюринга. А есть и иные способы выражения требований, декларативные или недирективные.. И даже не описание требований, а описание мотивов, ценностей, потребностей - это выше чем директивы
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Ну, для дата-сатанистов, как я понимаю, это самое что ни на есть приземленное.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Igor Bespalchuk
Ну, для дата-сатанистов, как я понимаю, это самое что ни на есть приземленное.
Возможно я отстал. Всё что видел в сатанизме, было на Python или R
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Sdobridnuk
ООП, и Яву лишь язык выражения требований. И явно зависит от 'тупости' исполняющий системы. Когда то ей надо было давать инструкции в машинных кодах, потом на ассемблере, потом на ЯВУ. Но это все императивные языки для машины тьюринга. А есть и иные способы выражения требований, декларативные или недирективные.. И даже не описание требований, а описание мотивов, ценностей, потребностей - это выше чем директивы
Я тут не соглашусь. Все-таки не требования мы описываем, а полноценную реализацию, иначе бы ничего не работало. Естественно, мы описываем на ЯВУ  конструкции некоторых работающих машин, поверх некоторой нижележащей виртуальной машины (ЯП), которая вводит свои понятия и что-то может делать в терминах этих понятий, например создавать и связывать "объекты".
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Gennadiy Kruglov
Возможно я отстал. Всё что видел в сатанизме, было на Python или R
источник

S

Sdobridnuk in Архитектура ИТ-решений
Alexey, ed101 это даже не документ, а лишь один из форматов сообщений платёжной системы. Как например авторизация по карте в iso 8583, или message type 103 в swift. Соответственно за пределами 5-10 человек в банке в РЦ его никто не знает и знать не обязан.. Под 'бланковыми' документами я понимаю первичные учётные документы, внесённые допустим в общероссийский классификатор и имеющие закрепленную ГОСТами, ФЗ единую форму представления и использования всеми гражданами и организациями РФ
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Оно кстати тоже поручение.
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Все вышесказанное не отменяет его причастность к физтехам
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Финтеху *
источник

S

Sdobridnuk in Архитектура ИТ-решений
Так это и беда, что мы связываем и требования и реализацию.. Это перегружает управляющий контур и 'оглупляет' исполнителя. Это как сказать жене - возьми 400 г нежирного творога, 2 айца, стакан мкуи, столовую ложку сахара, потом слепи на сухом столе комочки весом по 50 грамм, но не мочи... А можно проще, любимая сделай ка сырники по твоему фирменному рецепту, уж очень хочется поднять настроение уже от завтрака приготовленное руками любимой :)  и у вас будет масса вариантов реализации сырников, каждый день лучше другого...
источник

AM

Alexey Mergasov in Архитектура ИТ-решений
Уау... по теме то что? )))) ед101 юридически значимый первичный электронный документ.  Декларативно описывающий перевод с одного счета на другой. Чем не функция????
источник

S

Sdobridnuk in Архитектура ИТ-решений
Alexei, я промолчал кстати про ed101, что это платёжное поручение, не топил.. Но если вы и правда ляпнете что то про ' платёжное распоряжение' и его 'юридическую значимость' профи заказчикам в РЦ, и там не будет миллениалов и прочих айджалистов", которые не поймут подвоха.. То вас по доброму выставят за дверь и разговор будет навсегда закончен.. Есть вещи которые нельзя так инфантильно трактовать.. Особенно если это касается платежей и денег
источник