Здравствуйте, Сомов Александр, Вы писали:

AF>>Отцам основателям это удавалось. Секрет в том, что бы знать принципы построения языков и архитектуру используемых библиотек, а вот синтаксис — вовсе не обязательно...
СА>Да нормального уровня программист этот синтаксис освоит за неделю. А в течение месяца работы и фишечки. Уж никак незнанание языка не мешает писать программу. И архитектуру соответственно строить. А если её начинать строить сразу в коде — то на препятствия, налагаемые языком, можно быстро наткнуться и подработать архитектуру. А если её спустить программистам сверху, не зная языка, они будут вынуждены в коде писать какие-то ужасы, которые нафиг не нужны. Простой пример, напроектировать чего-то с применением обратных вызовов при использовании DCOM. Оно, конечно, пишется, но, как правило, проще использовать другое решение. И это — тот случай, когда нужно знать особенности даже не языка, а среды.
Вот именно после такого поверхностного освоения за неделю и рождаются монстры, которых потом программистам приходится потом и кровью выписывать. А простая мысль поговорить с программистами — которые всяко лучше разбираются в технологии — в голову не приходила?
Потом дело совсем в другом. Архитектуру в сложной системе нужно описывать так, что бы от кода вообще не зависела. Тут знание языка вообще может быть вредным — так как появляется тенденция подгонять архитектуру под сиюминутные потребности. Кроме того пример с DCOM как раз иллюстрирует ключевой момент о котором я и говорил:

Секрет в том, что бы знать принципы построения языков и архитектуру используемых библиотек, а вот синтаксис — вовсе не обязательно...

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

AF>>Затем, что любой язык, который применяется не для живого общения, а для документации — которую может читать специалист не знакомый с автором опуса, должен быть описан. Когда вы обясняете что то в живую вы как правило неявным образом договариваетесь о системе обозначений. Потому вас понимают и вы понимаете. Если что-то не понятно — вы можете об этом спросить отдельно. А теперь представьте, что вам принесли диаграмму — на которой неизвестные вам обозначения и спросить некого
СА>Ну этот десяток стрелочек (уж если захотелось что-то рисовать, а не использовать великий и могучий) — описать совсем не проблема. На это уйдёт час. А на освоение UML?
Вы хотите сказать, что архитектор или разработчик, которые легко за неделю осваивают синтаксис нового языка не в состоянии за ту же неделю понять, что означает десяток стрелочек?

Здравствуйте, Сомов Александр, Вы писали:

B>>Это смотря что вы понимаете под проектированием. В RUP, например, есть понятие модели анализа, модели дизайна и модели имплементации. Модель анализа независима от платформы/языка разработки ... модель дизайна совершенно спокойно модет быть сделана тоже независимой (это лишь вопрос квалификации проектировщика). А вот модель имплементации -- это уже с которой можно генерить исходный код на конкретном языке. Отсюда вывод -- можно, пользуясь вашим термином, ГРАМОТНО спроектировать систему, не зная досконально конкретные языки программирования, как минимум на уровне моделей анализа и дизайна. А имплементацию норамальный разработчик уже на конкретном языке сам напишет , оптимизируя вызовы и прочия ....

СА>Я правильно понимаю, что модель анализа — это ещё вовсе не архитектура классов? А всего лишь чётко выделенная структура предметной области?
СА>И то, что модель дизайна может быть независимой — это накладывает ограничения общность её описания? Т.е. я так понимаю, там не должно быть подробного описания взаимодействия объектов. Скорее уж описание модульного разделения системы и взаимодействия модулей. Так?

Цели у анализа могут быть самые разные — от выявления понятий предметной области до построения как полной модели предметной области, так и модели системы — включая как статику, так и динамику.

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

AR>Целиком поддерживаю, когда речь идет именно о процессе разработки. Использовать методологии UML для разработки неудобно и накладно, а тем более в небольших проектах. Нужны иные средства (Together и DSL вероятно как раз и есть движение в нужном направлении). В то же время нет никакого смысла заменять UML как средство визуализации. Возвращаясь к своей аналогии с PDF замечу, что все согласны использовать PDF-документы, когда надо обеспечить народ информацией. Но вот писать тексты сразу в формате PDF никто особо не стремится — все больше Word или другие текстовые редакторы пользуем.

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

Здравствуйте, Сомов Александр, Вы писали:

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

СА>Всё-таки, даже если в математических книгах и есть картинки, то они описывают не структуру формул, а, грубо говоря, результат их применения. А вот тот же UML — описывает как раз-таки более структуру. Аналогом картинок из математических книг в программировании были бы screenshot'ы.

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

Здравствуйте, Сомов Александр, Вы писали:

AF>>И что в 10% кода содержится описание того, что должно быть в остальных 90%?
AF>>Вселенная, конечно, фрактал, но не до такой же степени...
СА>Вселенная — нет. А грамотно спроектированный код — да. Вот те 90% "мешающегося" при понимании архитектуры кода очень легко спрятать. Этот давно известный приём ООП называется "инкапсуляция".

То есть вы возмьмётесь доволдить до победного конца проект, в котором описано 10% интерфейсов, классов и кода — без какой либо документации или других источников информации о том, что нужно делать?
Прежде чем читать лекции и бросаться умными словами вычитаными в книжках — подумайте исходя из обычного здравого смысла — если вы не знаете что делать и узнать неоткуда — как вы можете сделать именно то, что надо и не что-то случайное?

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

AF> В мелких проектах возможно и часто даже полезнее вообще обходиться бумагой и карандашом. Любое качественное документирование — что не применяй — стоит достаточно дорого для того, что бы не имело смысла его делать в небольшом проекте.

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

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

AR> Возвращаясь к своей аналогии с PDF замечу,
Я уже показывал, как ложна эта аналогия.

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

AR> Но никто пока не говорил, что архитектуру системы следует разрабатывать сразу в коде.
Я этоговорил с самого начала. Код, во всех средствах шел первым пунктом, но с завидным упорством этоого никто не замечал.

AR> Никому ведь не приходит в голову на словах описывать форму какой-нибудь шестеренки — ее чертеж говорит сам за себя и всем понятен.
Чертеж — это скриншот, а не UML-диаграма, если уж Вы без аналогий не можете.

Здравствуйте, Сомов Александр, Вы писали:

СА> Однако, это верно для очень квалифицированного программиста.
Естественно, но лично я с турдом себе представляю архитектора, который не является квалифицированным программистом...

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

AR>> Никому ведь не приходит в голову на словах описывать форму какой-нибудь шестеренки — ее чертеж говорит сам за себя и всем понятен.
M>Чертеж — это скриншот, а не UML-диаграма, если уж Вы без аналогий не можете.

Э, нет! Не соглашусь. Что же тогда фотография этой шестеренки? Именно чертеж, выполненный в рамках стандартов, можно считать аналогией UML-диаграммы. Также, как в чертеже приходится рисовать проекции с разных сторон, а иногда и отдельно изображать внутренности, так и UML-диаграммы приходится рисовать для разных частей системы, а отдельные важнейшие процессы выносить в отдельные диаграммы.

СА>>Всё-таки, даже если в математических книгах и есть картинки, то они описывают не структуру формул, а, грубо говоря, результат их применения. А вот тот же UML — описывает как раз-таки более структуру. Аналогом картинок из математических книг в программировании были бы screenshot'ы.

AF> То есть диаграмма последовательности взаимодействия двух систем друг с другом ближе к реальному коду, с его кучей ньансов, чем к обобщённому логическому описанию процесса?

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

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

AF>Здравствуйте, Сомов Александр, Вы писали:

AF>>>И что в 10% кода содержится описание того, что должно быть в остальных 90%?
AF>>>Вселенная, конечно, фрактал, но не до такой же степени...
СА>>Вселенная — нет. А грамотно спроектированный код — да. Вот те 90% "мешающегося" при понимании архитектуры кода очень легко спрятать. Этот давно известный приём ООП называется "инкапсуляция".

AF>То есть вы возмьмётесь доволдить до победного конца проект, в котором описано 10% интерфейсов, классов и кода — без какой либо документации или других источников информации о том, что нужно делать?
Не так, 10% кода должны отражать логику работу, а 90% — нюансы.

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

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

Опять же, из функциональных требований, которые сами по себе не требуют UML.

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

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

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

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

AR>Здравствуйте, Сомов Александр, Вы писали:

СА>>... Уж никак незнанание языка не мешает писать программу. И архитектуру соответственно строить. А если её начинать строить сразу в коде — то на препятствия, налагаемые языком, можно быстро наткнуться и подработать архитектуру. А если её спустить программистам сверху, не зная языка, они будут вынуждены в коде писать какие-то ужасы, которые нафиг не нужны. Простой пример, напроектировать чего-то с применением обратных вызовов при использовании DCOM. Оно, конечно, пишется, но, как правило, проще использовать другое решение. И это — тот случай, когда нужно знать особенности даже не языка, а среды.

AR>Вы привнесли нечто новое в этот спор. До вас тут спорили о том, стоит ли использовать UML для описания архитектуры или в процессе ее разработки. Некоторые убеждали в том, что в процессе разработки лучшим средством являются слюни и бумага. Но никто пока не говорил, что архитектуру системы следует разрабатывать сразу в коде. Т.е. по вашему мы не задумаваясь об архитектуре должны просто садиться и писать код, а там уже глядя в то, что у нас получилось, разбираться. Разумеется особенности среды знать нужно, но замчу также, что не всегда стоит адаптировать свою архитектуру под эти особенности, иногда можно подумать и выборе другой среды, более подходящей под вашу задумку.

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

Можно и выбирать среду под задачу, но тогда уже её нужно тоже знать. А речь ведь шла, о том, чтобы делать архитектуру без знания языка и среды.

AR>Если априори исходить из того, что UML никто не знает и знать не хочет, то ваше мнение имеет смысл. Но ведь это не так. И даже упомянутые вами стрелочки вы так хорошо и естественно понимаете и применяете именно потому, что чертежные стандарты давным давно прижились и были приняты всеми. Никому ведь не приходит в голову на словах описывать форму какой-нибудь шестеренки — ее чертеж говорит сам за себя и всем понятен. То же самое и в схемотехнике. Хотя здесь уже для ясного понимания процессов нужен и текст и осциллограммы и пр. (и никто кстати не отрицает необходимость и полезность упрощенных блок-схем). Более молодая область — графические изображения алгоритмов, все те же квадратики, ромбики и стрелочки, пониманию которых учат уже даже в школе. Неужели это не удобно и следует вернуться к великому и могучему? Описания структуры и порядка функционирования информационных систем понадобились относительно недавно. Поэтому и стандарты в этой сфере просто еще не успели окончательно сформироваться. Но отрицать их необходимость неверно.

Разумеется, удобно было бы такой стандарт иметь. И вот как раз в качестве такового UML кажется не очень удачным. В частности из-за того, что непонятно в качестве чего позиционируется. Всё же для разных видов деятельности нужны разные обозначения. А здесь пытаются его применить и для предметной области и для программной архитектуры и много ещё чего. Так его излишняя гибкость затрудняет его изучение и серьёзно снижает его ценность. Им просто неудобно пользоваться. Почти всегда легче написать слова, чем пытаться втискивать их в UML, при том, что слова ничуть не хуже (а зачастую лучше) будут поняты.

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

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

А что касается графического представления — оно не всегда лучше. Вот ту же математику я читал и без всяких картинок — и вполне неплохо. Когда менее 7 (+-2) объектов — их можно и из текста прочитав в уме держать, а когда больше — всё равно потонешь в деталях, даже если картинка перед тобой. Ну так я за то, чтобы код был так организован, чтобы эти детали были спрятаны. А не за то, чтобы делать графическую копию кода, в которой просто нет большого числа деталей.

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

AF>Здравствуйте, Сомов Александр, Вы писали:

AF> Вот именно после такого поверхностного освоения за неделю и рождаются монстры, которых потом программистам приходится потом и кровью выписывать. А простая мысль поговорить с программистами — которые всяко лучше разбираются в технологии — в голову не приходила?
Да вовсе нет. Своевременный грамотный рефакторинг ещё и из не таких дыр выбраться позволяет. Хуже, когда упорно пишутся всё новые и новые абстракции под архитектуру, которая ну никак не соответствует выбранной среде. Я год жил с такой спущенной сверху архитектурой. В итоге, её просто выкинули, а программа была отрефакторена. С тех пор она быстро и качественно развивается.

AF> Потом дело совсем в другом. Архитектуру в сложной системе нужно описывать так, что бы от кода вообще не зависела. Тут знание языка вообще может быть вредным — так как появляется тенденция подгонять архитектуру под сиюминутные потребности. Кроме того пример с DCOM как раз иллюстрирует ключевой момент о котором я и говорил:
AF>

AF>Секрет в том, что бы знать принципы построения языков и архитектуру используемых библиотек, а вот синтаксис — вовсе не обязательно...

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

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

AF>Если для вас архитектор это тот, кто разрабатывает всё и за всех, а остальные — тупые кодеры, то вы конечно правы. А вот если рассматривать архитектора как человека, который обеспечивает целостность постоения системы в целом — совсем не обязательно.
Ну первое вовсе не обязательно. Я ведь тоже могу условий напридумывать, при которых и вы правы безоговорочно (ну, например, при условии, что 2+2=5), но ведь эти условия не имеют отношения к вашей точке зрения. Также и я не придерживаюсь того, что "архитектор это тот, кто разрабатывает всё и за всех, а остальные — тупые кодеры". Ну а что без этого условия я прав не безоговорочно, так это для всех верно. Боги у нас на форуме не тусуются.

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

AF>>>Затем, что любой язык, который применяется не для живого общения, а для документации — которую может читать специалист не знакомый с автором опуса, должен быть описан. Когда вы обясняете что то в живую вы как правило неявным образом договариваетесь о системе обозначений. Потому вас понимают и вы понимаете. Если что-то не понятно — вы можете об этом спросить отдельно. А теперь представьте, что вам принесли диаграмму — на которой неизвестные вам обозначения и спросить некого
СА>>Ну этот десяток стрелочек (уж если захотелось что-то рисовать, а не использовать великий и могучий) — описать совсем не проблема. На это уйдёт час. А на освоение UML?
AF>Вы хотите сказать, что архитектор или разработчик, которые легко за неделю осваивают синтаксис нового языка не в состоянии за ту же неделю понять, что означает десяток стрелочек?
Освоит. Но зачем? До кучи?

СА>> Однако, это верно для очень квалифицированного программиста.
M>Естественно, но лично я с турдом себе представляю архитектора, который не является квалифицированным программистом...
А я об этом и говорю. Да здравствует код! Долой UML!

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

AF>Здравствуйте, Сомов Александр, Вы писали:

B>>>Это смотря что вы понимаете под проектированием. В RUP, например, есть понятие модели анализа, модели дизайна и модели имплементации. Модель анализа независима от платформы/языка разработки ... модель дизайна совершенно спокойно модет быть сделана тоже независимой (это лишь вопрос квалификации проектировщика). А вот модель имплементации -- это уже с которой можно генерить исходный код на конкретном языке. Отсюда вывод -- можно, пользуясь вашим термином, ГРАМОТНО спроектировать систему, не зная досконально конкретные языки программирования, как минимум на уровне моделей анализа и дизайна. А имплементацию норамальный разработчик уже на конкретном языке сам напишет , оптимизируя вызовы и прочия ....

СА>>Я правильно понимаю, что модель анализа — это ещё вовсе не архитектура классов? А всего лишь чётко выделенная структура предметной области?
СА>>И то, что модель дизайна может быть независимой — это накладывает ограничения общность её описания? Т.е. я так понимаю, там не должно быть подробного описания взаимодействия объектов. Скорее уж описание модульного разделения системы и взаимодействия модулей. Так?

AF>Цели у анализа могут быть самые разные — от выявления понятий предметной области до построения как полной модели предметной области, так и модели системы — включая как статику, так и динамику.

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

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

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

AF>> Это далеко не всегда возможно. Простой пример: разработка крупного программно-аппаратного комплекса. В таком комплексе зачастую одни и теже алгоритмы реализуются на различной аппаратуре, причём видов этой аппратуры — 30-40. Система структурируется и каждый уровень должен быть грамотно описан, что бы различные разработчики делали аппаратуру под один и тот же стандарт. Тем более, если часть аппратуры или ПО разрабатываются вовне — в другом городе и тем более стране. Вот и попробуй в таких условиях выделить 20-30 человек, которые всё сделают...

IT>А описывается стандарт или алгоритмы?

Описывать приходится всё что угодно:
— Общую идеологию
— Бизнес-процессы
— Структуру системы (из чего она состоит)
— Развёртывение системы (где что установлено и как это взаимодействует)
— Используемые технологии
— Интерфейсы
— Стандарты
— Алгоритмы
— Протоколы (как железячные так и программные)
И т.д. и т.п.

Здравствуйте, Сомов Александр, Вы писали:

СА>Разумеется, удобно было бы такой стандарт иметь. И вот как раз в качестве такового UML кажется не очень удачным. В частности из-за того, что непонятно в качестве чего позиционируется. Всё же для разных видов деятельности нужны разные обозначения. А здесь пытаются его применить и для предметной области и для программной архитектуры и много ещё чего. Так его излишняя гибкость затрудняет его изучение и серьёзно снижает его ценность. Им просто неудобно пользоваться. Почти всегда легче написать слова, чем пытаться втискивать их в UML, при том, что слова ничуть не хуже (а зачастую лучше) будут поняты.

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

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

А вот здесь я с вами вероятно согласен. Вы высказываете примерно те же мысли, которые я пытался объяснить в самом начале этого спора. Есть проблема с тем, что UML с самого своего возникновения пытается объять необъятное и залезть во все дыры, в то время как его реальная площадка гораздо уже. И проблему никак нельзя решить развитием/расширением UML (например, введением в него каких-то еще графов) — нужно развивать средства проектирования, работающие с исходным кодом.

Здравствуйте, ВСЕ УЧАСТНИКИ ОБСУЖДЕНИЯ, Вы писали:


Господа! Предлагаю определится с терминологией! А то, похоже, каждый под архитектурой понимает что-то свое:
кто бизнес логику, кто иерархию объектов, etc.