iscrafm,

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

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

Сложность оценивается и как сложность предметной области (число правил, объектов, связей, сущностей), так и "нелокальность правил" (т.е. правила затрагивают очень много различнх сущностей).

Теперь понятнее?

iscrafm,

Не за что.
Если еще что-нибудь про доклад можете сказать, то с удовольствием послушаю. Пора бы уже новую версию делать, добавлять новый опыт.

guest_20040621>
Интересно. Есть количественная шкала?

Нет, конечно. Тут и качественной то шкалы, по сути, нет. Просто когда смотришь на систему, прикидываешь нагрузку, то понимаешь, что очевидный шардинг не сработает (нелокальность бизнес-правил и связей), описание бизнес-объектов будет часто меняться (много бизнес-объектов), объем хранения большой (много сущностей и связей), затраты на моделирование бизнес-логики будут большие (много бизнес-правил) - и делаешь вывод, что стандартные правила разработки "сложных" систем или "высокнагруженных" систем не срабатывают и нужно искать непривычные решения.

guest_20040621,

Ох, сейчас, наверно, нет.
Вот к следующему году буду готовить курс для студентов, в нем, наверно, придется что-нибудь придумать.
Хотя, вроде бы, квалификации "скоростной анализ постановки" от них не требуется (а жаль...).

Я могу, конечно, попробовать проанализировать свою последовательность анализа системы при выборе метода решения. Но это очень субъективно - у меня компетентции во вполне конкретных областях, я берусь за вполне конкретный класс задач - и это очень сильно сказывается на выборе решений. В конце концов, все равно все решения зависят от людей :)

guest_20040621,

Боюсь, что только к концу лета :)
Пока как раз прорабатываю идеологию курса - и не факт, что вопросы выбора оптимальной архитектуры в курс вообще войдут. Но, может быть, где-нибудь выложу основные слайды и тексты. Формально то курс касается проектированию информационных систем, разработка архитектуры там - только одна и не самая важная часть.

ВМоисеевМы люди разные, мне интересно не только ЧТО надо делать, но и КАК.

Это просто опыта еще мало и поэтому всякие очевидные низкоуровневые вещи кажутся интересными.
Для меня, честно говоря, попытка написать собственный вариант TLS/SSL или понаступать на очевидные грабли в организации сериализации и работы с БД - ну совершенно не интересны. Собственно, большая часть ваших статей - это не слишком удачные попытки придумать давно известные велосипеды.
При это действительно сложные вещи - как сделать сложные распределенные транзакции, как обеспечить надежность хотя бы в .999, какие угрозы безопасности предусмотрены, как происходит балансировка нагрузки, поведение системы при отказе серверов - вообще не описаны.
Собственно, когда я вижу протокол, в котором не предусмотрена версионность, я уже представляю опыт человека в создании сколь-нибудь сложных систем.

p.s. много ли Вы имеете практики работы с VS и .Net Framework, чтобы судить?
Судить что именно? Качество Вашего кода или качество архитектурных решений или пригодность .Net к решению каких-либо задач?