Здравствуйте, Сергей Воробьев, Вы писали:

СВ>Здравствуйте, Mishka, Вы писали:

M>>Это всё из области логической архитектуры приложений.
СВ>"Логическая архитектура приложения" — нигде не нашел такого термина или определения. Дайте пожалуйста ваше понятие для разъяснения.

Как строить ПО не основываясь ни на каких технических решениях. Например, объектно-ориентированная архитектура — логическая. Моделируем всё в терминах объектов (Платон вроде бы был основателем). J2EE — физическая ОО архитектура. То есть имеется вполне осязаемый код (или стандарт), накладывающий ограничения на проектирование ПО. Из-за несоответствия между логической архитекутрой (идеал) и физической (то, что позволяет текущее развитие технологий) появляются всякие design patterns.

M>>Проблемы, которые ты перечислил, успешно решаются. Например при помощи SOA и BPM.
СВ>Спасибо, почитал.. Буду еще анализировать. Но на первый взгляд мне кажется, что это больше близко к уровню реализации, а не моделирования, проектирования, представления предметной области. Например, если представить уровни так: анализ предметной области — проектирование | моделирование — логическая | физическая реализация. Сразу говорю, что эти уровни в общем смысле несколько размыты.

Забудь про реализацию! SOA = service-oriented architecture. BPM = business process management. Обе вещи можно рассматривать отдельно от IT. Например, возьмём университет. Если думать в смысле SOA, то он обеспечивает определённый сервис — обучение, исследования, пр. Если в смысле OOA, то он состоит из кафедр, студентов, профессоров, исследований и пр.
Две разные точки зрения на один и тот же объект. Ни больше, ни меньше. На сегодняшний день SOA считается лучшим вариантом, поскольку намного ближе отображает действительность корпоративного мира. Возможно другие миры (наука, искусство и пр.) могут быть смоделированы при помощи других средств, но меня этот вопрос как-то не занимает
Управление бизнес процессами принимает за аксиому то, что весь бизнес состоит из процессов. Улучшение процессов и их оптимизация — это основная цель бизнеса, поскольку это улучшает сам бизнес. Из другой области, химическая реакция — это тоже бизнес процесс, изменить его может и нельзя, но управлять (контролировать, обеспечивать условия, ресурсы) всё равно необходимо.

Как работает корпорация? Люди из отдела маркетинга, занимающие позиции product managers, выясняют что нужно рынку, то есть определяют продукт. Продукт — это набор физических вещей и услуг, объединённый под одним названием (брандом). Например, продукт Microsoft Office — включет в себя программы, руководство пользователя, техническую поддержку, рекламную компанию и пр. Product Managers отвечают за дизайн продукта. Они точно знают что должно быть в продукте, чтобы его можно было продать. Далее, отделы корпорации получают задание на разработку продукта. Конкретнее, отдел IT получает документ с требованиями к функциональности программы (программа — это не продукт, это обычно малая его часть). В этот момент бизнес аналитики начинают исследовать предметную область, а технические архитекторы — строить необходимую инфраструктуру. Когда всё готово, программисты садятся и пишут код.
Так это происходит в больших конторах. В маленьких, обычно product managers — это бизнес аналитики, а архитекторы — программисты.
Логическая архитектура должна применяться на уровне product manager-ов, поскольку они владельцы продукта. Для них ООА не шибко замечательный подход, а вот SOA — самое то. Бизнес обеспечивает сервисы для своих клиетов. Каждый сервис состоит из бизнесс-процессов. Это product managers понимают и готовы описывать требования к функциональности ПО в этих терминах. Если затем имеется подходящая инфраструктура (BPMS, WfMS), то разработка ПО сильно упрощается.

M>>Система не должна быть сложной. Она должна быть модульной. Каждый модуль "владеет" своими данными и полностью не зависим от других модулей. В последнем предложении заменям модуль на сервис и приходим к SOA
СВ>А я и не говорил, что она не модульная. Она сложная, потому что там "много всего". "Полностью независим" — это в идеале, все равно есть случаи, когда при изменении какой-либо части не удается полностью добиться независимости. Вот тогда и начинается "подгонка" с нарушением всех правил "моделирования". А потом все это нарастает как снежный ком и приводит к провалу проекта. Иногда конечно спасает рефакторинг, но не всегда это возможно.

Рефакторинг придуман людьми от XP, которые таким образом борются с изначальным отсутствием дизайна. Маленькие проекты так ещё можно делать, но большие — нет. Всё равно нужна логическая архитектура, физическая архитектура и инфраструктура. А полной независимости можно добиться при использовании event-driven architecture, только там модули уж слишком независимы