Правильно вы написали про архитектуру. Если сказать более простым языком, то архитектура это "а вот здесь у нас будут фасады, а тут DAO, а тут вот сервисы дёргаются, а вот тут вот интеграция и т.д."

А UC это "пользователь нажал, система сохранила, система загрузила, система отправила, пользователь получил" — здесь нет (как и в бизнес модели, построенной по UC и похожей на диаграмму классов) поробностей реализации, так как это более высокий уровень абстракции, который навряд ли будет меняться, даже если вы с java на .net перейдёте.


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

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

VGn>>Варианты использования — термин управления требованиями. Use cases с архитектурой не связаны.
VGn>>И если можно ещё поспорить о связи акторов с доменной моделью, то механизм доступа к БД, как и наличие собственно БД с вариантами использования не связаны абсолютно.

AS>Механизм доступа к БД с вариантами(прецедентами) использования не связан ибо на момент
AS>формирования use case разработчик может и не знать вовсе какая база данных будет использоваться,
AS>а может она будет и не одна.

AS>Вы уж извините за мою безграничную безграмотность, но что же тогда представляет из себя архитектура системы?
AS>Нашел на сайте ibm.com :
AS>"Архитектура — это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением,
AS>а также принципы, определяющие проектирование и развитие системы. [IEEE 1471]"

AS>Разве у нас на основе use case'ов и доменной модели, а в последствии модели классов не получаются компоненты(.dll)?