S>>"In a top-down approach an overview of the system is first formulated" куда больше подходит к модели предметной области и архитектуре, чем к дизайнерским наброскам UI.

T>Почему?

Поясню свой вопрос. Я согласен, что фраза "In a top-down approach an overview of the system is first formulated" говорит об архитектуре. Но не о любой архитектуре, а именно о той, что удовлетворяет требованиям. То есть требования первичны.

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

T>>Да. Интерфейс определяет не только набор операций, а скорее контракт, в который также входят обязательства всех сторон.
S>И нефункциональные тоже?

Любые.

День добрый, mrTwister.

Перечитал топик — ужаснулся. Попробую для разнообразияф не возбуждать флейма, а спокойно объяснить свою точку зрения.

Для начала надо просто сесть и изучить матчасть-
http://www.intuit.ru/department/se/progstyles/14/4.html

Не самый лучший источник, зато лёгким языком + видно отличия обоих подходов.

На самом деле тут неприменимо разделение. При использовании модели предметной области у вас будет нисходящее проектирование по-любому — там идёт именно движение от общего (модели) к частному — деталям реализации.

Когда вы пытаетесь использовать UI как модель, у вас получается смешивание обоих подходов: вы рассматриваете UI как универсальную модель системы, и в то же время создаёте эту модель из частных нюансов реализации. Аноним приводил пример — у него проект зависел от выбора компонента редактирования — IE или Scintilla. И общая модель получалась слепленной из сотен таких вот решений, без каких-либо объективных критериев кроме одного — так вы видите взаимодействие системы с внешним миром.

Я вижу крайне ограниченный набор решений, где такой подход подойдёт — главным образом самплы, иллюстрирующие различные паттерны реализации UI. Во всех остальных случаях закладываться на частичное описание и строить по нему архитектуру невыгодно. Во-первых, представление ничего не говорит об архитектуре. Если несогласны — напишите, я разовью мысль. Во-вторых, архитектура создаётся как нечто долгоживущее, она помогает структурировать проект и упрощает внесение изменений. В третьих, UI — одна из самых недолговечных штук в программе, оно меняется вслед за любыми изменениями требований. Архитектура, наоборот, меняться не должна.

Всё это — при грамотном проектировании. Если у вас неопытная команда — вы можете напроектировать что угодно, но стабильным это будет вряд ли — тут нужен опыт. Если хорошая архитектура упрощает разработку, то плохая, наоборот, способна испортить весь проект. Возможно поэтому agile-методики так упирают на человеческие ценности, гибкость и Храбрость (почитайте сами про последнее, там не совсем обычное значение вкладывается).

То же самое человеческим языком. У вас есть куча маленьких "что оно должно делать", которые никак не зацеплены вместе — вам придётся придумывать способ сцепления самому. Эти "что оно должно делать" определяются желанием заказчика автоматизировать часть своей работы. Работает он в некоторой предметной области — в теории, эти "что оно должно делать" должны описываться в терминах этой предметной области. Несогласны — напишите, объясню. Если мы будем использовать модель, то у нас раз — появляется метод объединения всей этой фигни в одно целое, и два — мы можем описать "что оно должно делать" в терминах предметной области и фактически получить высокоуровневое описание БЛ. Заметьте, до сих пор ваше видение никуда не вмешивается, всё объективно. Зато ваша фантазия отыграется на превращении "что оно должно делать" в "как это будет работать". Поскольку вы заранее видите точки пересечения (из высокоуровневого описания БЛ), вы можете переиспользовать один и тот же код, и, главное, когда у вас поменяются требования, вы будете исправлять не косяки реализации, а несоответствие вашей модели изменившейся ситуации.

То же самое кратко — модель предметной области позволяет манипулировать гораздо большим объёмом объективной информации и строить обоснованные решения. Обоснованием будет не "я так вижу", или "так сказал заказчик", а описание операции в терминах предметной области. С этим уже можно спорить, находить ошибки и неточности и т.п.

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

P.S. Пользователь — необязательно живой человек, в роли пользователя может выступать что угодно. Если хотите, чтобы не было разногласий можно использовать корявый термин "внешний агент".

Дня вам.

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

S>Перечитал топик — ужаснулся. Попробую для разнообразияф не возбуждать флейма, а спокойно объяснить свою точку зрения.

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

S>На самом деле тут неприменимо разделение. При использовании модели предметной области у вас будет нисходящее проектирование по-любому — там идёт именно движение от общего (модели) к частному — деталям реализации.

Ошибка номер один и главная в данной дискуссии: модель не является общей.
Модель является частной абстракцией предметной области созданой на основе требований к программному продукту.

S>Я вижу крайне ограниченный набор решений, где такой подход подойдёт — главным образом самплы, иллюстрирующие различные паттерны реализации UI. Во всех остальных случаях закладываться на частичное описание и строить по нему архитектуру невыгодно. Во-первых, представление ничего не говорит об архитектуре. Если несогласны — напишите, я разовью мысль. Во-вторых, архитектура создаётся как нечто долгоживущее, она помогает структурировать проект и упрощает внесение изменений. В третьих, UI — одна из самых недолговечных штук в программе, оно меняется вслед за любыми изменениями требований. Архитектура, наоборот, меняться не должна.

И? Это не означает, что архитектуру необходимо создавать не думая об интерфейсе. Тебе пытаются сказать, что первое, что следует сделать при построении архитектуры — определить интерфейс системы. Исходя из него уже можно принимать архитектурные решения. Без него — архитектура может быть максимально гибкой, но все равно претерпит изменения еще до изменений требований. Т.е. в процессе создания продукта.

S>Всё это — при грамотном проектировании. Если у вас неопытная команда — вы можете напроектировать что угодно, но стабильным это будет вряд ли — тут нужен опыт. Если хорошая архитектура упрощает разработку, то плохая, наоборот, способна испортить весь проект. Возможно поэтому agile-методики так упирают на человеческие ценности, гибкость и Храбрость (почитайте сами про последнее, там не совсем обычное значение вкладывается).

А вот тут ты уже тролишь. И меряешься. Не зачет.

S>То же самое человеческим языком. У вас есть куча маленьких "что оно должно делать", которые никак не зацеплены вместе — вам придётся придумывать способ сцепления самому. Эти "что оно должно делать" определяются желанием заказчика автоматизировать часть своей работы. Работает он в некоторой предметной области — в теории, эти "что оно должно делать" должны описываться в терминах этой предметной области. Несогласны — напишите, объясню.

Пока все верно, все обычно так и происходит.

S>Если мы будем использовать модель, то у нас раз — появляется метод объединения всей этой фигни в одно целое, и два — мы можем описать "что оно должно делать" в терминах предметной области и фактически получить высокоуровневое описание БЛ.

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

S> Заметьте, до сих пор ваше видение никуда не вмешивается, всё объективно.

Ошибка номер два:
Любая модель субъективна и строится на основе видения архитектором предметной области.

S>Зато ваша фантазия отыграется на превращении "что оно должно делать" в "как это будет работать".

Именно с этого и следует начинать, только в процессе понимания как оно будет работать может родиться хорошая модель.

S>Поскольку вы заранее видите точки пересечения (из высокоуровневого описания БЛ), вы можете переиспользовать один и тот же код, и, главное, когда у вас поменяются требования, вы будете исправлять не косяки реализации, а несоответствие вашей модели изменившейся ситуации.

Это верно. Причем для подхода который я пытаюсь тебе объяснить даже в большей степени верно.

S>То же самое кратко — модель предметной области позволяет манипулировать гораздо большим объёмом объективной информации и строить обоснованные решения.

Чем что?

S>Обоснованием будет не "я так вижу", или "так сказал заказчик", а описание операции в терминах предметной области. С этим уже можно спорить, находить ошибки и неточности и т.п.

Описание в терминах предметной области не требует модели.

Здравствуйте, Ziaw.

Откуда обвинения в троллизме? Я вроде адекватно вам отвечал... не будем — ещё одна ветка холивара.

Ошибка номер один и главная в данной дискуссии: снова и снова перевирать чужие слова, давать им собственное значение и упрекаеть на основе этого в собеседника в идиотизме. Собсно дискуссия шла в духе:
— почему "архитектура — функция от требований"?
— а как ещё можно?
— вон например в DDD предлагают модель предметной области...
— это неправильно! модель определяется требованиями!
— почему? вон например в DDD не модель не определяется требованиями и может служить основанием для архитектуры...
— это неправильно! Архитектура определятеся требованиями! (вариант: Архитектура определяется интерфейсами)

Меня эдакий диалог в одну сторону утомляет. Тем не менее — ещё одна цитата. (когда же с вашей стороны хоть одна будет?)

http://www.domaindrivendesign.org/:

Over the last decade or two, a philosophy has developed as an undercurrent in the object community. The premise of domain-driven design is two-fold:
For most software projects, the primary focus should be on the domain and domain logic; and
Complex domain designs should be based on a model.
Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

Мне уже n-й раз подсовывают слово "требование" там где я его упоминал и радостно орут "гы! дурак! модель определяется требованиями" в ответ на предложение в котором я писал что модель — отражение предметной области и используется для описания требований и алгоритма их реализации в терминах предметной области. Чуствуете разницу?

На вопрос откуда возникает модель я уже отвечал Aikin:

S>>Вы идёте именно по тому пути, что я описал выше — строите архитектуру от предположений заказчика о требуемом функционале — кто вам виноват, что архитектура меняется вслед за требованиями?
A>А от чего еще его строить. Предположения заказчика и мой собственный опыт это все что у меня есть.

Ну не совсем. Предложения заказчика — это то, чего он хочет сейчас. Вы можете узнать долгосрочные цели, как система будет использоваться/расти в будущем, с кем будет интегрироваться и т.п. и закладываться на это (разумеется с должной подстраховкой).

Но главное — здесь с Эвансом я полностью согласен — у вас есть информация, которая вполне вероятно переживёт и заказчика и ваш продукт и вас самих. Это предметная область (или Domain если вам ближе Эванс). Грубо говоря домен описывает пограничные условия, которые могут быть нарушены только при нарушении самой предметной области. Я не могу изложить всё так же ровно и гладко — почитайте "Domain-Driven-Design: Tackling the complicity in the heart of development". Только не воспринимайте всё близко к сердцу — Эванс отнюдь не идеал

Там есть пара интересных методик — от адаптации моделей при интервьюировании (слово-то какое гадкое...) до рекомендаций по использованию модели как словарика терминологии, как части документации, как сочетать DDD с методологиями и т.п. Читать стоит хотя бы для самообразования.

Модель предметной области не скажет вам ничего о конкретной деятельности заказчика. Зато она вам даст примерную модель данных (я не говорю о воспомогательных табличках). Терминология и связи между сущностями — это тоже очень много. Далее, сопоставляя требования с этой моделью вы увидите что часть идеально ложится на модель, а часть требует серьёзных переделок. Почти наверняка эти требования возникают когда заказчик хочет странного и скорее всего в первую очередь будут меняться в будущем. Ещё как вариант — эти требования не попадают в модель из-за того что вы что-то упустили при построении модели. Или заказчик (точнее, консультант) чего-то не знает в предметной области.

и ниже

A>А как ты узнаешь о предметной области? Однажды утром проснешься со всем необходимым объемом знаний?

Если вы не читали Эванса — есть куча неявных источников информации о предметной области. Самый простой — обсуждение требований. Цель выделение того, что Эванс называет "неявным знанием" — той информации которая кажется очевидной специалистам и последние просто её не упоминают. Он приводит пример с расписанием авиаперевозок. Из требований выходило что-то типа "исходный-конечный аэропорт + время прилёта/отлёта". Во время собеседования было совершенно случайно выяснено, что вообще-то расписание определяется планом полёта, а его лучше рассматривать как последовательность четырёхмерных точек (3 координаты + время). Дальше выясняется о связи узловых точек с навигационными маяками и заранее утверждёнными трассами. И так далее.

Вся эта информация оказалась крайне важна, но в требованиях о ней не было ни слова. Эта информация определяется не пожеланиями заказчика, а предметной областью — она объективна. Если её не учитывать её на ранних этапах — она косвенно всплывёт позже через изменения требований, например в виде проверки соблюдения полётного плана или визуализации рейсов.

Именно такие требования чаще всего и приводят к изменению архитектуры.

Сама логика DDD безумно примитивна — заказчик в идеальном случае строит свои требования в ответ на изменения в окружающей среде. Так зачем моделировать среду косвенно, через требования заказчика, если можно моделировать её прямо?

Есть ещё куча способов изучения предментной области. Самые примитивные — консультация со сторонними специалистами/самостоятельное изучение.

и вам (кстати, там же и про "субъективность" модели):

Z>В этом и есть ваша ошибка, модель сильно зависит от требований и часто меняется вместе с ними.

От того, что заказчик придумал новый тип ценников кардинально поменялся принцип интернет-торговли??? Боюсь, вы ненамеренно включаете в модель быстро изменяющуюся информацию и заявляете что модель зависит от требований. Вы их разделите.
Хотя бы так: модель предметной области влияет на архитектуру, требования заказчика — на функционал. Хоть это и неправда...

Гммм... вот смотрите. Вы пишете автоматизацию логистики. Или интернет-магазин. Или социальную сеть. (во всём вышеперечисленном одинаково некомпетентен ). И везде-везде внутренняя логика работы зависит от требований заказчика???

Для вас предметная область функция от требований — "заказчик хочет магазин — сделаем". Для меня наоборот — заказчик работает в определённой области, он подчиняется правилам, принятым в этой области (не изобретает же он нечто совершенно особое?), и информация об этой области заведомо переживёт все его хотелки. Независимо от желания заказчика в магазине будут товары, персонал, покупатели и т.п. и будут известны некоторые "правила игры" типа "персонал не продаётся" (ну это смотря какой магазин...).

Предметная область _независима_ от желаний заказчика. Как бы он не выёживался, ничего нового в рамках области он не придумает — он играет по правилам. Правила неявно присутствуют в каждом требовании и выцарапать их оттуда практически невозможно. Но если поменяются правила — поменяются требования и вам всё равно придётся изменять продукт. Только разница будет в том, что в первом случае вы _знаете_ причину изменений, а во втором _угадываете_.

Вы так и не ответили — дальше беседа шла про ведущую роль UI в определении архитектуры. Теперь этот же вопрос задаётся ещё раз. Не надоело?

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

S>На самом деле тут неприменимо разделение. При использовании модели предметной области у вас будет нисходящее проектирование по-любому — там идёт именно движение от общего (модели) к частному — деталям реализации.

В том числе.

S>Когда вы пытаетесь использовать UI как модель, у вас получается смешивание обоих подходов: вы рассматриваете UI как универсальную модель системы, и в то же время создаёте эту модель из частных нюансов реализации. Аноним приводил пример — у него проект зависел от выбора компонента редактирования — IE или Scintilla. И общая модель получалась слепленной из сотен таких вот решений, без каких-либо объективных критериев кроме одного — так вы видите взаимодействие системы с внешним миром.

Интерфейс — это не модель предметной области, а её проекция. Интерфейс привносит дополнительные требования, которым должна удовлетворять архитектура. Проблема в том, что эти требования в принципе не могут появиться в результате анализа и построения модели предметной области (так как они там не отражены вообще), несмотря на то, что они могут иметь фатальное влияние на архитектуру. Например, мы разработали замечательную модель предметной области, реализовали её в уровне бизнес-логики и пытаемся прикрутить интерфейс. Заказчик говорит: хочу прогресс-бар для некоторой длительной операции и чтобы показывалось, что в данный момент происходит. И мы понимаем, что это сделать невозможно, так как уровень бизнес-логики, реализующий модель предметной области, предоставляет нам лишь синхронный метод для запуска этой длительной операции и что мы просто не в состоянии сюда прикрутить прогресс-бар с уведомлениями. И вообще, интерфейс зависает при каждом обращении к бизнес-логике. Чтобы решить эти проблемы, мы должны полностью переработать архитектуру реализации модели домена, введя туда асинхронные операции и многопоточность. Несмотря на то, что концептуально модель не поменялась, код придется выкинуть и переписать заново. Если бы мы с самого начала продумали интерфейс, то у нас бы заранее появилось требование к архитектуре поддержки асинхронных операций и сама реализация модели была бы уже совершенно другой.

S>То же самое человеческим языком. У вас есть куча маленьких "что оно должно делать", которые никак не зацеплены вместе — вам придётся придумывать способ сцепления самому.

Разумеется. Никто не говорит, что архитектура не нужна. Вопрос лишь о том, с чего начинать её проектирвоать.

S>Эти "что оно должно делать" определяются желанием заказчика автоматизировать часть своей работы. Работает он в некоторой предметной области — в теории, эти "что оно должно делать" должны описываться в терминах этой предметной области. Несогласны — напишите, объясню. Если мы будем использовать модель, то у нас раз — появляется метод объединения всей этой фигни в одно целое, и два — мы можем описать "что оно должно делать" в терминах предметной области и фактически получить высокоуровневое описание БЛ. Заметьте, до сих пор ваше видение никуда не вмешивается, всё объективно. Зато ваша фантазия отыграется на превращении "что оно должно делать" в "как это будет работать". Поскольку вы заранее видите точки пересечения (из высокоуровневого описания БЛ), вы можете переиспользовать один и тот же код, и, главное, когда у вас поменяются требования, вы будете исправлять не косяки реализации, а несоответствие вашей модели изменившейся ситуации.

Для этого есть бизнес и системные аналитики, в задачу которых входит анализ предметной области, рисование диаграмм, построение моделей и прочее. Но то, что наваяют аналитики совсем не обязательно должно быть перенесено на код "один в один".

Ок, принято.

С налёту ответить не получится — тут думать надо.

Если коротко: все требования, которые накладываются UI стоит рассматривать после того, как мы уже расписали БЛ в терминах предметной области и перед тем, как мы переходим к проектированию реализации — заодно с другими техническими нюансами. Т.е. это задачи второго плана — от необходимости изменить представление не поменяются ни другие требования, ни БЛ (мы наивно считаем что она определена верно).

Принято?

В предыдущем посте я как-то умудрился обойти этот вопрос, точнее отделался предложением "зато ваша фантазия отыграется на превращении из "что оно должно делать" в "как оно будет работать"". Такие вопросы просто рассматриваются уровнем ниже и являются частью процесса превращения модели в код. На этом этапе всё что вы написали верно — за исключением пары моментов.

Детали реализации не отражаются в модели, точно так же как не отражаются требования.
Если мы реализуем модель используя MVC, то получится следующее: для данных (они частично отражают модельпредметной области, с учётом нюансов, определяемых БЛ) абсолютно параллельно, в каком потоке их изменяют — главное чтобы не нарушались ограничения.

Для реализации логики, что живёт в контроллере тоже как бы всё равно — её можно запускать асинхронно или параллельно — она не проектировалась исходя из информации об окружении. Остаётся UI. Допустим у нас STA. Следовательно, остаётся воспользоваться стандартными механизмами конкретного фреймворка для перенаправления обработчиков событий, что живут в code behavior в главный поток. Если у нас WinForms, то любой контрол реализует интерфейс ISynchronizable (сорри, по памяти), если WPF — то любой IDispatcherObject умеет то что нам надо.

В вашем примере контроллер бы просто выставлял наружу соответствующие события (типа progress changed, если опреацию нельзя отразить по-другому), а сам запускал бы длительную операцию через ThreadPool. В гуе добавится кастомный BindingSource, который редиректит события изменения списка в главный поток. Редирект обработчиков событий контроллера работает точно так же. Всё решается силами code behavior. Структуру данных для этого изменять не придётся, логика операций также не меняется.

Смысл такого подхода — в последовательном разбиении крупной задачи на маленькие кусочки и решение их, не затрагивая по возможности остальные части системы. В идеале мы должны предусмотреть в самом начале проекта критерии для выбора фреймворка типа "длительная задача может быть запущена в другом потоке — поэтому фреймворк должен поддерживать MTA либо предоставлять механизм синхронизации контектстов".

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

Извиняюсь за возможно бессвязный ответ, исчезаю до вторника.
Удачи.

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

S>Я знал, я знал Была у меня такая мыслишка... — уж слишком много уделяется внимания уникальности методологии и священным методикам. Скромно посчитал, что я ещё не проникся вселенской мудростью

Вы слишком грамотно для начинающего по полочкам методологии раскладываете . Чувствуется прям математический подход и школа. Провоцируете публику, короче, я думаю так .

G>>Детальный дизайн — алгоритмы и структуры данных.
G>>Дизайн — разбиение функциональности по компонентам, модулям, или классам.
G>>Архитектура — то, что не перечисленное. Комплекс базовых технологий, на которые опирается решение, плюс — идиом или паттернов проектирования, заложенных в "ядро", "фреймворк", или философию построения системы. Если перечисленное вообще есть. Скажем, вы решили, что сериализация объектов у вас будет всегда в XML — это архитектурное решение.

S>Ок. Принято. Вопрос: должен ли дизайн (с архитектурой вроде всем ясно) проектироваться исключительно на основе требований? (Вопрос провокационный, больше чтобы было от чего идти). Если нет, как можно компенсировать перекос дизайна из-за учёта только актуальных требований?

Да должен. Уточню определение, чтобы избежать множественного толкования.

Архитектура — есть набор ограничений для дизайна. Именно ограничений, в чем они выражены — в виде существования некоторого кода, возможностями которого надо пользоваться, или же правил, которым надо следовать — неважно.

Архитектура реализует класс требований. Это — "стратегический дизайн", цель которого — выигрышь в долговременной перспективе, а не в контексте данного проекта с данными требованиями.

Дизайн — исходит их текущих требований, плюс ограничения, диктуемые архитектурой. Если ограничения нам сильно прям мешают, можно внести правку архитектуры. Целесообразность правки решается по месту по критерию riskk-value-cost.

Теперь я точно ответил на Ваш вопрос? Не, натурально приятно иметь дело с умным человеком . Даже понятно, гже в вопросе подвох, и отрадно что он есть . Или я подвох упустил? Тады вдвойне приятно .

G>>Разумеется, надо принимать во внимание как требования, так и технические ограничения, так и ваши возможности (знаем Java — архитектура будет базироваться на Java а не дотнет). Будущие требования тоже имеют значение. Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли? .

S>Да-да, уже легче Вообще-то вопрос был о том, почему два-три товарища так настойчиво утверждают, что "архитектура — функция от требований". Пока ответ -"расхождение в определениях". Остались смутные сомнения — может товарищей всё-таки посетило дао?

Насчет дао — сомневаюсь, а уж почему они настойчиво утверждают то, что утверждают — так ваще понятия не имею. Уровень конфы у нас ИМХО упал за последнее время.

S>Интересно также ваше мнение про модель бизнеса — я не могу придумать других рациональных объясенений такой агрессивной пропаганде решений "здесь и сейчас". Или это только моя мнительность и кто-то кроме вас говорил о "надо принимать во внимание как требования, так и технические ограничения, так и ваши возможности" и "Будущие требования тоже имеют значение"?

По моему это простой здравый смысл. Любой реалистичный план исходит в первую очередь из ваших возможностей. Если в эти возможности не входит снятие технических ограничений — надо учитывать и их. Потому, что вложение в технологию — дорогостоящая штука, это стратегическое решение. Как впрочем и ее разработка. А что требований — так нафига делать то, что никому не нужно? Архитетура — это стратегический дизайн, который по сути есть набор ограничений для тактического дизайна. Этим все сказано ИМХО.

Разве это не очевидно? А раз так, то какое имеет значение, кто говорил так до меня? На вскидку думаю, я в этом сойдусь с Rumbaugh, Cantor, DeLuka, и Booch. Хотя мои заключения и основаны на моем опыте, а не на цитатах.

Здравствуйте, Gaperton, Вы писали:
G>По моему это простой здравый смысл. Любой реалистичный план исходит в первую очередь из ваших возможностей. Если в эти возможности не входит снятие технических ограничений — надо учитывать и их. Потому, что вложение в технологию — дорогостоящая штука, это стратегическое решение. Как впрочем и ее разработка. А что требований — так нафига делать то, что никому не нужно? Архитетура — это стратегический дизайн, который по сути есть набор ограничений для тактического дизайна. Этим все сказано ИМХО.

Другими словами, я понимаю архитектуру как результат и основной составной элемент процесса стратегического планирования. Составной элемент — потому, что этот процесс непрерывен, и архитектура должна корректироваться по ходу времени, отражая представление о будущем, угрозах, рисках, и возможностях. Текущая архитектура может отличаться от "эталонной", которая отражает текущие представления, и ничего страшного в этом нет — работы по рефакторингу привязываются к плану текущих работ, диктуемых текущими требованиями, но — вектор направления в дизайне всегда в сторону "эталонной" архитектуры.

Теперь, вероятно, я полностью ответил на поднятый Вами вопрос.

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

B>>Архитектор — "технарь", он не должен выдумывать требования.
S>Бизнес-требования — согласен. Уточнение: архитектура (я всё ещё использую определения Gaperton'a. Как они там доспорят — посмотрим ) накладывает некоторые ограничения и их можно трактовать как дополнительные требования к функционалу. Согласны?

Найн. Это принципиальный момент. Вы не можете трактовать ограничения на дизайн, диктуемые архитектурой, как часть дополнительных требований к функционалу, и вообще — требований. Во-первых, ограничение не есть требование. Во-вторых, это не часть _внешних_ требований — это то, над чем вы имеете контроль, и что вы можете изменить. Пусть вам это дорого обойдется, но вы это можете изменить, и вашему "заказчику", то есть источнику требований, на эти ограничения глубоко пофигу. Эти ограничения — ваши проблемы, и техники управления требованиями никак вам не помогут с ними обойтись.

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

G>Другими словами, я понимаю архитектуру как результат и основной составной элемент процесса стратегического планирования. Составной элемент — потому, что этот процесс непрерывен, и архитектура должна корректироваться по ходу времени, отражая представление о будущем, угрозах, рисках, и возможностях. Текущая архитектура может отличаться от "эталонной", которая отражает текущие представления, и ничего страшного в этом нет — работы по рефакторингу привязываются к плану текущих работ, диктуемых текущими требованиями, но — вектор направления в дизайне всегда в сторону "эталонной" архитектуры.

...что хорошим менеджером будет либо архитектор (technical lead), либо специалист в предметной области (product manager). Другие менеджеры, владеющие исключительно pmbok-ами и прочим балшытом — объявляются офисным планктоном и подлежат сокращению во время текущего мирового финансового кризиса . Ну разве что если речь не идет о заказных разработках, когда "менеджер" — это во многом еще и sales manager.

Человек решил задать этот вопрос менеджерам — пусть отвечают менеджеры. Оставить здесь, я считаю.

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

S>>Да-да, уже легче Вообще-то вопрос был о том, почему два-три товарища так настойчиво утверждают, что "архитектура — функция от требований". Пока ответ -"расхождение в определениях". Остались смутные сомнения — может товарищей всё-таки посетило дао?

T>Это "дао" — древняя, испытанная штука (как и положено быть дао). Называется оно: "проектирование сверху-вниз".

Не менее древними и испытанными являются "снизу вверх" (подход проектирования в языке FORTH), и "от центра к краям" (как говорили тогда, к такому подходу прибегают самые малочисленные и опытные). Что дальше будем делать? Древнее знание — оно всеоблемлюще, в частности, знатоки говорят, можно для любой ситуации подобрать цитату из Маркса.

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

B>>>Определение дизайна я дать не могу. Но я бы предположил, что указанные три термина могли бы обозначать следующее:
B>>>Возмем систему, со всеми ее классами и пр. = Детальный дизайн

G>>Код, это очевидно, не "детальный дизайн". Код — это код. Ошибка кодирования четко отличается от ошибки детального дизайна. Одно дело ошибиться в алгоритме, или выбрать неподходящую структуру данных, и совсем другое дело — ошибка кодирования. Определение детального дизайна я взял из PSP/TSP, где все эти определения берутся из классификатора ошибок. В UML для описания алгоритмов в принципе подойдет activity диаграмма, однако честнее и правильнее сказать что UML детальный дизайн не покрывает. Детальный дизайн — это уровень "псевдокода".

B>Все очень просто. Я не встречал упоминания одновременно трех этих терминов. "Дизайн — Детальный дизайн" то бишь "Архитектура — Дизайн" или "Стратегический — тактический дизайн" — это было. А вот "Архитектура — Дизайн — Детальный дизайн" — нет. Поэтому я предположил, что могли бы означать эти три термина вместе.

А я для пользы дела предлагаю разделить их на три категории. Независимо от того, было это уже или нет — а потому, что так кажется правильно.

B>Но, вернемся к Вашему посту.
B>

B>Детальный дизайн — алгоритмы и структуры данных.
B>Дизайн — разбиение функциональности по компонентам, модулям, или классам.
B>Архитектура — то, что не перечисленное. Комплекс базовых технологий, на которые опирается решение, плюс — идиом или паттернов проектирования, заложенных в "ядро", "фреймворк", или философию построения системы. Если перечисленное вообще есть. Скажем, вы решили, что сериализация объектов у вас будет всегда в XML — это архитектурное решение.

B>Я не согласен с выделенным. Как минимум, потому что архитектура включает в себя разбиение по компонентам и их взамодействие. Но Вы эти элементы архитектуры исключили.
B>Поэтому считаю Ваше определение архитектуры, м-м-м... не полным.

"То, что не перечисленное" — плохое определение. В первую очередь потому, что допускает двадцать пять толкований. Расширенное, более точное и непротиворечивое определение архитектуры — здесь, и ниже по ветке.
http://rsdn.ru/forum/message/3302674.1.aspx

Автор: Gaperton
Дата: 23.02.09

Прошу комментироать по нему.

Дня вам!

Ухх, понаотвечали... Бум разгребаться по-порядку.

Для начала извиняюсь за слегка съехавшую в сторону дискуссию — увлёкся общением. С другой стороны, подняли тему — когда я спокойно беседовал с Sshur было только 3 страницы умных людей. Что называется — почуствуйте разницу

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

Теперь попробуем пройтись по вопросу "почему дизайн не стоит определять только требованиями".
Для начала — архитектура у вас отражает две вещи — глобальные технические решения (разделение на слои/используемые фреймворки/описание практик и т.п. — всё то, что можно назвать воплощённым опытом команды) и некоторое стратегическое видение (если оно есть). Я правильно понял?

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

Здесь подвох в том, что со стратегической частью архитектура получает те же проблемы что и дизайн — она точно так же строится с учётом требований, только изменяется медленнее и требования не настолько очевидны. Хорошо это или плохо — не скажу. Я наверно рассматривал бы стратегическое видение как набор индикаторных требований (corner cases) для проверки возможностей платформы. Например, путём такой вводжной: в будущем потребовалось то-то и то-то, оценить как повлияет на архитектуру, оценить исправления, принять меры. Возможно, мы говорим об одном и том же разными словами.

У меня остались опасения насчёт дизайна (если мы всё ещё говорим о разбиении функционала). Я не считаю, что в требованиях содержится достаточно информации для создания стабильного разбиения (подвох здесь). С другой стороны, вы ничего не говорили о способе которым должно проводиться это разбиение. По дефолту предполагается, что это обязанность системных аналитиков/архитекторов: скармливаем требования (+ возможно абстрактное описание БЛ) — на выходе дизайн.

Давайте договоримся, что изменение разбиения чего-то стоит и от качественного разбиения есть какой-то выигрыш (этакая гипотеза ad hoc для того чтобы было о чём спорить).

Я вижу как минимум один способ пролучить "качественное" разбиение — явное выделение предметной области (как некоторой статичной модели) и описание требований исключительно в терминах предметной области. Идея утянута у Эванса, но есть нюансы(с) — Эванс включает в модель БЛ и получает одноразовую модель, которая подходит только для конкретного проекта у конкретного заказчика.

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

В первом случае мы модифицируем модель (а это произошло бы в любом случае, только мы не угадываем, а отражаем существующие изменения). Во втором — мы пытаемся получить корректное требование и как правило можем его получить, потому что говорим на том же языке, что и заказчик и можем обоснованно описать ситуацию.

Собсно дизайн превращается в ещё одну модель — в действующую модель БЛ и работает поверх общей модели предметной области. Когда мы переходим к реализации дизайна — у нас всплывает архитектура. Точнее не так — архитектура облегчает и обеспечивает реализацию дизайна (если хотите, получение детального дизайна).

По моему, при таком подходе можно проигнорировать аргументы про то. что детально проработанный дизайн/архитектура — слишком дорогое удовольствие и должны определяться стратегией (опять провокация). Несогласны?

Поскольку написано слишком много — умолкну.

Спасибо!

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


S>Я вижу как минимум один способ пролучить "качественное" разбиение — явное выделение предметной области (как некоторой статичной модели) и описание требований исключительно в терминах предметной области. Идея утянута у Эванса, но есть нюансы(с) — Эванс включает в модель БЛ и получает одноразовую модель, которая подходит только для конкретного проекта у конкретного заказчика.

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

S>В первом случае мы модифицируем модель (а это произошло бы в любом случае, только мы не угадываем, а отражаем существующие изменения). Во втором — мы пытаемся получить корректное требование и как правило можем его получить, потому что говорим на том же языке, что и заказчик и можем обоснованно описать ситуацию.

S>Собсно дизайн превращается в ещё одну модель — в действующую модель БЛ и работает поверх общей модели предметной области. Когда мы переходим к реализации дизайна — у нас всплывает архитектура. Точнее не так — архитектура облегчает и обеспечивает реализацию дизайна (если хотите, получение детального дизайна).

Слова человека, укушенного DDD.
Уже есть укушенные Agile, укушенные ООП и укушенные Столлманом, теперь новый вид появился.
(не в обиду сказано)

Все называть моделью конечно можно, но не нужно, и даже вредно так как ведет к неверному толкованию.

Дрямс вам!

Кстати, не угадали — имел опыт с проектированием от моделей в разных областях, так что слегка в теме.
Эванс ничего особо нового не придумал — он поцитатил старые работы, заинлайнил пару идей и очень удачно поднялся на интересе к Agile.

У DDD свои недостатки — начиная с того что она нежизнеспособна как отдельная методология (впрочем, тут всё честно написано на офсайте) и заканчивая тем, что они не могут разобраться с разделением моделей — живёт у них таки БЛ в модели или нет, что есть структура данных, и как быть с cross-domain операциями, которые неизбежно порождают искуственные сущности.

В принципе я мог бы с тем же успехом цитатить идеи Дейта, описание архитектуры типовой СУБД в терминах стандарта 71-го года или любую книжку по смаллталку. В DDD основные идеи расписаны применительно к ТРПП — переводить не надо.

Что у вас вызывает конкретную неприязнь? Вроде я говорил раньше только о модели предметной области и не называл моделью всё... Если вы про моё восприятие дизайна — можете спокойно выкинуть этот абзац. Там скорее неправильная аналогия выходит, а не конкретные утверждения.

Если есть чего конкретного — напишите, призадумаюсь. Если нет — всё равно пишите, пообсуждаем.

Удачи!

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

S>Дрямс вам!

S>Кстати, не угадали — имел опыт с проектированием от моделей в разных областях, так что слегка в теме.
S>Эванс ничего особо нового не придумал — он поцитатил старые работы, заинлайнил пару идей и очень удачно поднялся на интересе к Agile.

S>У DDD свои недостатки — начиная с того что она нежизнеспособна как отдельная методология (впрочем, тут всё честно написано на офсайте) и заканчивая тем, что они не могут разобраться с разделением моделей — живёт у них таки БЛ в модели или нет, что есть структура данных, и как быть с cross-domain операциями, которые неизбежно порождают искуственные сущности.

S>В принципе я мог бы с тем же успехом цитатить идеи Дейта, описание архитектуры типовой СУБД в терминах стандарта 71-го года или любую книжку по смаллталку. В DDD основные идеи расписаны применительно к ТРПП — переводить не надо.

S>Что у вас вызывает конкретную неприязнь? Вроде я говорил раньше только о модели предметной области и не называл моделью всё... Если вы про моё восприятие дизайна — можете спокойно выкинуть этот абзац. Там скорее неправильная аналогия выходит, а не конкретные утверждения.

S>Если есть чего конкретного — напишите, призадумаюсь. Если нет — всё равно пишите, пообсуждаем.

S>Удачи!

Как всегда стоит иметь несколько взглядов на архитектуру и дизайн приложения. Если ограничиваться только DDD, то неизменно загоните себя в ситуацию когда новые требования не ложаться в DDD.

Здравствуйте, gandjustas.

Забавно — выше я вроде бы писал, что на DDD не стоит зацикливаться и что у него тоже есть свои недостатки. Свои позиции расписывал кучу раз в этом топике. Кстати, вы можете мне привести пример "когда новые требования не ложаться в DDD" или это так, для поддержания беседы?

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

S>Здравствуйте, gandjustas.

S>Забавно — выше я вроде бы писал, что на DDD не стоит зацикливаться и что у него тоже есть свои недостатки. Свои позиции расписывал кучу раз в этом топике.
А потом обзываете все что можно моделью.

S>Кстати, вы можете мне привести пример "когда новые требования не ложаться в DDD" или это так, для поддержания беседы?
Не могу, не занимаюсь проектированием по DDD.