В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

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

qwarta.ru подробнее

Size: a a a

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

2177 membersпожаловаться на группу
2020 June 11

RT

Roman Tsirulnikov in Архитектура ИТ-решений
это развязывает сервисы: сервис отправивший событие не знает того кто это событие прочитает и как обработает,
то есть условный сервис “платеж” вообще не знает что где-т оесть сервис с лентой истории, собирающий его события
источник
21:46пожаловаться#1

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, это один из вариантов. Зато при таком подходе сложно восстановить всю логику происходящего и что произойдет при изменении формата этого самого события (или какой-то неочевидной семантики типа "решили на стадии авторизации тоже отправлять события того же типа"
источник
21:47пожаловаться#2

PD

Phil Delgyado in Архитектура ИТ-решений
Но, реально, пофиг. Читает топик или слушает порт. Все равно же EntityService
источник
21:48пожаловаться#3

PD

Phil Delgyado in Архитектура ИТ-решений
Там нет логики. Там только прочитать топик и записать что в этом топике прилетело.
источник
21:48пожаловаться#4

PD

Phil Delgyado in Архитектура ИТ-решений
И потом отдать по фильтру.
источник
21:48пожаловаться#5

PD

Phil Delgyado in Архитектура ИТ-решений
И ты все равно думаешь, что и куда надо послать, что бы оно попало в историю. Т.е. все равно помнишь связь сервиса платежа и сервиса истории.
источник
21:49пожаловаться#6

RT

Roman Tsirulnikov in Архитектура ИТ-решений
В любой системе ты все равно должен знать бизнес-процесс, магии никто тут не обещал.
В инженерной практике всегда улучшая одни характиристики, приходится жертвовать другими, улучшения одновременно всех показателей почти никогда не бывает.
источник
21:52пожаловаться#7

RT

Roman Tsirulnikov in Архитектура ИТ-решений
На мой взгляд самое большое зло в сложной системе это возможность “быстренько тут вот добавить поле”.
Just Do It это худшая практика в ИТ
источник
21:53пожаловаться#8

RT

Roman Tsirulnikov in Архитектура ИТ-решений
размотать потом этот Big Ball Of Mud будет стоить миллионы юнитов ресурсов уже через год
источник
21:54пожаловаться#9

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, по разному. Скорее "быстренько добавить поле" можно только в специально отведенных местах. Изолированных от прочей логики.
источник
21:59пожаловаться#10

PD

Phil Delgyado in Архитектура ИТ-решений
Но если про EnityService.
Внутри агрегата - они вполне допустимы.
Реализция внешнего API агрегата в виде CRUD Entity Service - скорее всего нет.
источник
22:02пожаловаться#11

PD

Phil Delgyado in Архитектура ИТ-решений
(Как и хореографию я скорее пущу между агрегатами, а внутри - будет оркестрация)
источник
22:02пожаловаться#12

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Я последние лет пять поклонник подходов ФП. Многие паттерны применяются и к архитектуре.
источник
22:06пожаловаться#13

PD

Phil Delgyado in Архитектура ИТ-решений
А какие?
источник
22:08пожаловаться#14

RT

Roman Tsirulnikov in Архитектура ИТ-решений
например принцип immutability, принцип отсувтствия сайд-эффектов, сведение модели данных к событиям
источник
22:18пожаловаться#15

RT

Roman Tsirulnikov in Архитектура ИТ-решений
мы сейчас проектируем сервис где почти нет операций UPDATE. Соотв. нет никаких блокировок/синхронизаций вообще, все очень легко масштабируется.
источник
22:20пожаловаться#16

PD

Phil Delgyado in Архитектура ИТ-решений
Очень хочется как-нибудь посмотреть вживую. Мне пока не удалось придумать схему, где домен было бы удобно описывать в функциональной парадигме. Не отдельные сервисы, а агрегат целиком
источник
22:32пожаловаться#17
2020 June 12

A

Alexey in Архитектура ИТ-решений
Roman Tsirulnikov
мы сейчас проектируем сервис где почти нет операций UPDATE. Соотв. нет никаких блокировок/синхронизаций вообще, все очень легко масштабируется.
А как же тогда вычислять условный остаток по карте в момент авторизации транзакции?
источник
00:40пожаловаться#18

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, для этого update в базу не нужен, достаточно хранить текущий стейт в памяти, а в хранилище - транзакции от предыдущего сохраненного состояния
источник
00:42пожаловаться#19

PD

Phil Delgyado in Архитектура ИТ-решений
Я так ещё лет 15 назад делал, иначе никаких iops не хватит.
источник
00:43пожаловаться#20