Comments on Систематизация автоматизации: CQS – конец монополии систем реляционных баз данны...

Вот еще встретилось и может быть полезно http://my...

2009-12-01T12:12:24.430+02:00

Вот еще встретилось и может быть полезно http://myshop.codeplex.com/

Семпл по мотивам CQS

К какому именно случаю вы попытались все это приме...

2009-11-20T01:04:21.928+02:00

К какому именно случаю вы попытались все это применить? Возможно, проблема была именно в не совсем подходящем примере.

Еще, возможно вы найдете ответы на некоторые вопросы здесь. Ну и пройдитесь еще раз по указанным ссылкам.

Пораскинув мозгами, и попробовав наструячить пару ...

2009-11-17T14:40:08.676+02:00

Пораскинув мозгами, и попробовав наструячить пару тестовых примеров по вашему предложению, мне стало уже 100% понятно, что кроме геморроя предложенный вами(или не вами) способ, больше ничего не приносит.
То есть если мы даже хоть какой, то мнимый плюс при работе с моделью. То этот плюс превращается в огромный минус, когда дело касается реализации данных методов.
И в целом мне непонятна ситуация, зачем такой огород городить. Например, выделение OLAP служит для увеличения скорости построения отчетов, и основной костыль с которым все мирятся – что OLAP база может содержать устаревшую информацию.
Но в вашем случае вы делает 2 базы и еще Notify между ними, что бы их держать в одинаковом состоянии, но зачем это надо, когда можно используя инструменты базы данных, такие как View и StoreProc реализовать точно такую, же систему, то есть у вас структура базы одна, но для приложения она совершенно другая.

например, так. хотя, все зависит от случая. class...

2009-11-12T16:43:15.550+02:00

например, так. хотя, все зависит от случая.

class QuarterDiscount : Entity
{
Percentage Percentage { get; set; }

public UpdatePercentage(Percentage newValue)
{
Percentage = newValue;
}

public Amount Apply(Amount amount)
{
return amount * percentage;
}
}

Игорь, можете поподробнее описать QuarterDiscount....

2009-11-12T16:35:58.045+02:00

Игорь, можете поподробнее описать QuarterDiscount.

To C...R...a...S...H Тут следует отличать действи...

2009-11-12T13:34:17.198+02:00

To C...R...a...S...H

Тут следует отличать действительно отчетные данные, которые никак не влияют на логику домена, и данные, которые домену нужны.

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

А вообще, вы затронули интересную тему, о которой я умышлено не написал.

Вся эта система работает хорошо, когда она, скажем так, не развивается. Когда вы запускаете механизм, все данные куда-то ходят, все где-то аккумулируется и таким образом поддерживается актуальное состояние системы.

А как быть, если, скажем на любом из уровней, добавляются новые типы "аккумуляторов", которые должны работать так, как если бы они были в системе последние лет 10...

Вот тут есть о чем поговорить :)

2Meowth: А никто и не говорит об абсолютной новиз...

2009-11-12T13:23:17.327+02:00

2Meowth:

А никто и не говорит об абсолютной новизне подхода. Тут все дело лишь в точке приложения этого подхода: если приложение сильно data-centric, то все будет делаться на основе Master/Subscriber. Если же приложение behaviour-centric, то это будет называться CQS.

Нужно отметить, что схема Master/Subscriber вполне себе может сочетаться и с CQS на уровне кода. Оно все и так сильно оторвано друг от друга. Никаких догм здесь нет - во всем следует быть прагматиком :)

Игорь, а как ваша архитектура будет обслуживать та...

2009-11-12T13:02:02.404+02:00

Игорь, а как ваша архитектура будет обслуживать такие требования бизнеса, которые строятся на отчетной информации.
Наприме: Клиент автоматически получает скидку, равную 3% от средней стоимости заказов за последний год(месяц, квартал, эру...).

На самом деле, схема репликации Master(RW) - Subsc...

2009-11-11T16:39:25.124+02:00

На самом деле, схема репликации Master(RW) - Subscriber(RO) (для снижения нагрузки) организует что-то подобное, только там по прагматическим причинам используются RDB и для того звена, что у вас названо ReportingDB.
Подход в данном случае интересный, но спорный.

На самом то деле, если уже бояться проблемы эквива...

2009-11-09T16:44:18.259+02:00

На самом то деле, если уже бояться проблемы эквивалентности/актуальности данных, то надо отключить кеши всех уровней, сделать запрос на получение данных с подтверждением. Фактически базаданных репортов может расматриваться как кеш. Кеш с возможностью принудительной актуализацией данных. Собсно я так понимаю именно для этого и рождаються паттерны на подобие Event Sourcing.

Я как раз постарался избежать вывода какого-то шаб...

2009-11-09T11:33:43.799+02:00

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

А проблема эквивалентности дублирующихся данных всегда появляется в тот самый момент, когда в табличке Order появляется колонка Total :)

Если серьезно, то я бы назвал это не проблемой эквивалентности, а проблемой актуальности данных.

И не был бы столь категоричен в неприятии такого разделения. Потому на другой чаше весов с актуальностью данных находится высокая степень доступности системы (та, которая high availability). И применимость того или иного решения зависит исключительно специфики домена и от важности этих показателей для бизнеса.

Мне совсем не нравится схема с сепарированными "Re...

2009-11-09T10:15:54.567+02:00

Мне совсем не нравится схема с сепарированными "Reports Data" и "Domain Data". Почему? Потому что, не существует способа позволяющего получить 100% гарантию еквивалентности данных хранящихся в этих двух хранилищах. А для бизнес приложения нет хуже ошибки, чем несоответствие данных в отчетах реальному положению дел. Такая ошибка сразу и навсегда убивает доверие пользователей к системе.
Да, разделение БД на OLAP и OLTP имеет место, но обычно по причине невозможности решить OLAP задачи на OLTP базе. Но рекомендовать такой подход в качестве шаблонного и всеобщего я бы не стал.