Вы можете пойти другим путем: - реализовать сервисную часть на native aot и запускать ее, например, как службу windows или предоставлять как общую библиотеку - реализовать отдельно ui-часть
если обеспечить совместимость на уровне контракта, то вы сможете обновлять лишь нужную часть, а не требовать перекачки всего приложения. к тому же станет очень очевидным, где лежит самая тяжелая часть приложения.
p.s. всё-таки, на мой взгляд, native aot - это больше про оптимизации, когда вы решили работать напрямую с памятью, указателями и т.п., но не желаете менять язык, и в большинстве проектов в этом нет необходимости - это нецелесообразно. а чтобы приложение от долгого старта не казалось зависшим - есть отдельные приемы для визуализации этого процесса.
Сохраняйте историю изменений (журнал) изменений по счету. Это будет lock free. Пример:
зарезервировать списание со СЧЕТ_1 на сумму X на момент времени T зарезервировать пополнение на счет СЧЕТ_2 на сумму X проверить, что на момент времени T на счете СЧЕТ_1 положительный баланс зафиксировать списание зафиксировать пополнение
outbox, например, для надежности. пополнение и списание не обязаны фиксироваться одновременно.
Это условная реализация, которая осуществляет взаимодействие с базой данных и при этом не требует использования транзакций - что, как я понимаю, вы ошибочно называете "протеканием абстракции". Эта реализация позволит не оборачивать код, который использует метод Deposit (в вашем варианте) в транзакцию, т.е. не раскрывать уровнем выше (в вашем прикладном коде, который использует абстракцию), что взаимодействие осуществляется с бд и нужно это держать в уме.
class Counter : ICounter
{
public void AddDeposit(decimal amount)
{
db.Insert(amount, timestamp, state);
}
public decimal GetDeposit(...)
{
return db.SelectAll().Where(...).Sum();
}
}
Добавление timestamp позволит собирать данные на момент времени. Добавление sessionId и state (Reserved/Fixed/Rejected) позволит сделать "откат" операции (пометить запись как отклоненную)
Если, например. мы работаем с банковским счетом, то при частом списании такая модель, на мой взгляд, отлично работает без каких-либо явных транзакций, позволяя зачислять и списывать средства. Если на счете не хватает денег, то можно делать откаты. При этом имеем полный аудит из коробки и ничего не нужно вычитывать несколько раз для модификации.
Нигде ничего не течет.
То, что где-то течет - это может быть как компромисом, чтобы не усложнять какие-то вещи, так и ошибкой проектирования системы.
Это не проблема ООП, это задача разработчика правильно выбрать способ решения задачи.
Сам подход работает, если вы замените бд на коллекцию в памяти. Никакого раскрытия уровнем выше абстракции (т.е. коду, который ее использует не потребуется знание, что под капотом абстракции для корректного взаимодействия с ней)
Хоспади. Не всякий код, который вы накалякали обязан быть thread-safe по умолчанию. Нужно понимать контекст и границы применимости тех реализаций, которые вы используете.
При распределенной системе, проблемы конкурентности есть при написании на любом языке. К ООП это не имеет отношения.
В рамках одной программы есть множество способов уйти от конкурентного доступа к объекту и вообще не использовать никаких примитивов синхронизации для работы с ним.
Что-то у вас с терминологией вообще плохо. Протекание абстракции - это раскрытие реализации, к многопотоку это не имеет ни малейшего отношения. И то, что какие-то реализации "non-safe-thread" - это лишь ограничение реализации, и к протеканию абстракции не имеет отношения.
Чисто для справки. Протекание абстракции - это не проблема реализации, и происходит тогда, когда абстракция раскрывает внутренние механизмы, которые должна была скрывать.
Два вызова метода increment из двух разных потоков приведет к тому, что мы дважды вычитаем предыдущее значение из базы, а потом дважды запишем обратно его же, увеличенное на единицу. Классический off-by-one в условиях высококонкурентной среды.
А что касается этого. Так сохраняйте события в бд (операция, значение, метка времени) + сжатие (например, на основе метки времени). Тогда никаких вычитываний для модификации не потребуется. Добавьте однопоточный механизм сжатия секвенции событий на основе метки времени, если не нужен детальный аудит изменений, либо используйте сжатие для аггрегации, чтобы быстро получать актуальное значение на определенный момент времени. То что у вас конкурентность вылезла - лишь проблема вашей реализации и архитектуры.
Вы не учитываете такие вещи как инфляция и тип платежа по кредиту.
Общая логика выбора гасить или вкладывать проста: если условно за 1/4 оставшегося срока вы способны собрать всю сумму задолженности (при равных ставках кредитования и дохода или ее часть как их отношение в прямой пропорции), то вкладывайте, иначе - гасите.
К слову. Вместо наследования (как и реализации интерфейса для сущности), чтобы не создавать god object, есть композиция.
Никто не мешает создать обработчик для конкретной анемичной бизнес-модели и в нем проводить нужные действия.
Таким образом, отправка письма - один обработчик, формирование заказа - другой и т.п.. И нет никакого смешивания различных бизнес-процессов в одном объекте.
Далее организовываем шину событий и подписку на них. Делаем обработчики событий, которые вызывают обработчики бизнес-моделей. Остается открытым лишь вопрос, наделять ли возможностью обработчики моделей отправой событий. Лично на мой взгляд - не стоит, лучше всего обработчики моделей (метоты) моделировать так, чтобы они возвращали статус работы, а решение принимать уровнем выше. Это также благоприятно скажется на тестировании, т.к. обработчики будут иметь более простую логику и меньшее кол-во зависимостей внутри.
Масштабируемость приложения не определяется интерфейсом сервиса.
Вас послушать: добавь к постгресу рестфулл интерфейс и он станет легко масштабируемым. Это не так.
Гибкость. Рестфул является в общем случае подходом, который строится поверх вполне конкретных технологий: требование к http-серверу и json формату данных, как самому распространенному - вполне себе конкретные технологии
Удобочитаемость. В сравнении с чем удобнее? Как на счёт протобафа, который дает и типизацию и более простой и более богатый формат описания контракта?
Есть ли сравнение с microsoft FASTER?
Вы можете пойти другим путем:
- реализовать сервисную часть на native aot и запускать ее, например, как службу windows или предоставлять как общую библиотеку
- реализовать отдельно ui-часть
если обеспечить совместимость на уровне контракта, то вы сможете обновлять лишь нужную часть, а не требовать перекачки всего приложения. к тому же станет очень очевидным, где лежит самая тяжелая часть приложения.
p.s. всё-таки, на мой взгляд, native aot - это больше про оптимизации, когда вы решили работать напрямую с памятью, указателями и т.п., но не желаете менять язык, и в большинстве проектов в этом нет необходимости - это нецелесообразно.
а чтобы приложение от долгого старта не казалось зависшим - есть отдельные приемы для визуализации этого процесса.
Сохраняйте историю изменений (журнал) изменений по счету. Это будет lock free.
Пример:
зарезервировать списание со СЧЕТ_1 на сумму X на момент времени T
зарезервировать пополнение на счет СЧЕТ_2 на сумму X
проверить, что на момент времени T на счете СЧЕТ_1 положительный баланс
зафиксировать списание
зафиксировать пополнение
outbox, например, для надежности. пополнение и списание не обязаны фиксироваться одновременно.
Это абстракция, она чистая и нигде не протекает, т.к. не раскрывает своей реализации
Это условная реализация, которая осуществляет взаимодействие с базой данных и при этом не требует использования транзакций - что, как я понимаю, вы ошибочно называете "протеканием абстракции".
Эта реализация позволит не оборачивать код, который использует метод
Deposit(в вашем варианте) в транзакцию, т.е. не раскрывать уровнем выше (в вашем прикладном коде, который использует абстракцию), что взаимодействие осуществляется с бд и нужно это держать в уме.Добавление timestamp позволит собирать данные на момент времени. Добавление sessionId и state (Reserved/Fixed/Rejected) позволит сделать "откат" операции (пометить запись как отклоненную)
Если, например. мы работаем с банковским счетом, то при частом списании такая модель, на мой взгляд, отлично работает без каких-либо явных транзакций, позволяя зачислять и списывать средства.
Если на счете не хватает денег, то можно делать откаты.
При этом имеем полный аудит из коробки и ничего не нужно вычитывать несколько раз для модификации.
Нигде ничего не течет.
То, что где-то течет - это может быть как компромисом, чтобы не усложнять какие-то вещи, так и ошибкой проектирования системы.
Это не проблема ООП, это задача разработчика правильно выбрать способ решения задачи.
Сам подход работает, если вы замените бд на коллекцию в памяти. Никакого раскрытия уровнем выше абстракции (т.е. коду, который ее использует не потребуется знание, что под капотом абстракции для корректного взаимодействия с ней)
Хоспади. Не всякий код, который вы накалякали обязан быть thread-safe по умолчанию. Нужно понимать контекст и границы применимости тех реализаций, которые вы используете.
При распределенной системе, проблемы конкурентности есть при написании на любом языке. К ООП это не имеет отношения.
В рамках одной программы есть множество способов уйти от конкурентного доступа к объекту и вообще не использовать никаких примитивов синхронизации для работы с ним.
Что-то у вас с терминологией вообще плохо. Протекание абстракции - это раскрытие реализации, к многопотоку это не имеет ни малейшего отношения. И то, что какие-то реализации "non-safe-thread" - это лишь ограничение реализации, и к протеканию абстракции не имеет отношения.
Причем тут вообще бд? Я рассказал о подходе, а бд там у вас или обычный список с полным перебором для поиска записи - вообще без разницы.
Чисто для справки. Протекание абстракции - это не проблема реализации, и происходит тогда, когда абстракция раскрывает внутренние механизмы, которые должна была скрывать.
А что касается этого. Так сохраняйте события в бд (операция, значение, метка времени) + сжатие (например, на основе метки времени). Тогда никаких вычитываний для модификации не потребуется. Добавьте однопоточный механизм сжатия секвенции событий на основе метки времени, если не нужен детальный аудит изменений, либо используйте сжатие для аггрегации, чтобы быстро получать актуальное значение на определенный момент времени. То что у вас конкурентность вылезла - лишь проблема вашей реализации и архитектуры.
Вы не учитываете такие вещи как инфляция и тип платежа по кредиту.
Общая логика выбора гасить или вкладывать проста: если условно за 1/4 оставшегося срока вы способны собрать всю сумму задолженности (при равных ставках кредитования и дохода или ее часть как их отношение в прямой пропорции), то вкладывайте, иначе - гасите.
Вы забыли в статье расписать еще один психотип "душнила". Считаю, что иначе картина неполна.
У меня к вам вопрос. Почему вы решили, что ит-ипотека направлена именно на помощь молодых "специалистов", а не на привлечение специалистов?
К слову. Вместо наследования (как и реализации интерфейса для сущности), чтобы не создавать god object, есть композиция.
Никто не мешает создать обработчик для конкретной анемичной бизнес-модели и в нем проводить нужные действия.
Таким образом, отправка письма - один обработчик, формирование заказа - другой и т.п.. И нет никакого смешивания различных бизнес-процессов в одном объекте.
Далее организовываем шину событий и подписку на них.
Делаем обработчики событий, которые вызывают обработчики бизнес-моделей.
Остается открытым лишь вопрос, наделять ли возможностью обработчики моделей отправой событий. Лично на мой взгляд - не стоит, лучше всего обработчики моделей (метоты) моделировать так, чтобы они возвращали статус работы, а решение принимать уровнем выше. Это также благоприятно скажется на тестировании, т.к. обработчики будут иметь более простую логику и меньшее кол-во зависимостей внутри.
Он был сильным эмпатом)
А потом будет новинка от создателя "outlook как сервер приложений" - "google таблицы как распределённая база данных"
Хочешь жить - умей учиться))
Мир сделает новый виток и будет спрос на специалистов другого направления. В свое время так число лошадей и кучеров сократилось, их сменил автомобиль.
Господи, спасибо тебе за протобаф.
Дайте две пиалы чая этому господину.
"Критикуешь - предлагай" - это чудесный способ замалчивать проблемы.
Масштабируемость приложения не определяется интерфейсом сервиса.
Вас послушать: добавь к постгресу рестфулл интерфейс и он станет легко масштабируемым. Это не так.
Гибкость. Рестфул является в общем случае подходом, который строится поверх вполне конкретных технологий: требование к http-серверу и json формату данных, как самому распространенному - вполне себе конкретные технологии
Удобочитаемость. В сравнении с чем удобнее? Как на счёт протобафа, который дает и типизацию и более простой и более богатый формат описания контракта?
Да ты просто не понимаешь: написано же "облегчает")))