glaznoyЗдравствуйте,
За пол года я научился кодить относительно быстро.
Теперь хотелось бы углубиться в проектировании и архитектуру приложений под .NET(C#).
Посоветуйте - с чего можно начать?
Архитектурные вопросы как правило не связаны с конкретным стеком технологий.
Начните в следующем порядке:

Обязательно:
1. Приемы объектно-ориентированного проектирования. Паттерны проектирования
Эрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес, Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес
2. Архитектура корпоративных программных приложений
Мартин Фаулер
+ Фаулер работает над описание новых паттернов, кот можно посотреть на его сайте
http://martinfowler.com/eaaDev

Желательно:
3. Применение DDD и шаблонов проектирования. Проблемно-ориентированное проектирование приложений с примерами на C# и .NET
Джимми Нильссон
4. C# и CSLA . NET Framework. Разработка бизнес-объектов
Лотка Р.
5. Core JEE Patterns
6. Шаблоны реализации корпоративных приложений. Кент Бек

Далее, если будете заниматься интеграционными проектами - обязательно:
Шаблоны интеграции корпоративных приложений
Грегор Хоп, Б. Вульф

Далее в подсказках по поводу источников уже не будете нужаться.
Удачи.

Petro123-1 :)
Архитектура в ЯП Очень сильно отличается. И уровень у Архитектуры (фреймворки) - выше, чем структуры данных.
Как сказал один местный модератор, Java и NET(C#) это параллельные вселенные.
-1 :)
Я так не считаю, так же как и Фаулер, Нильсен и Эванс, приводя в описании паттернов примеры для обеих платформ.
Не считают также и такие направления индустрии MDA и DSL, абстрагируясь от конкретной платформы/языка.
Даже во 2-ой и 3-ей части Sun Certified Enterprise Architect, относящегося к конкретной платформе - нет ни единой строчки на Java.
Результат вы сдаете в виде UML-диаграмм и описываете свой выбор паттернов.
Реализация платформ .NET и Java действительно довольно различная, не смотря на общие пересекающиеся стандарты, но в тоже время общего также много.
В любом случае, если кто-либо собирается заниматься архитектурой, ему следует абстрагироваться от конкретной платформы и языков. Я никогда не слышал о таком понятии как "Архитектура языков программирования" - оно ошибочное даже если где-либо и упоминается. У языка программирования есть синтаксис и грамматика.
Архитектурные же фреймворки - это вообще понятие которое стоит еще дальше от конкретных платформ и языков и включает в себя не только взгляд IT.
К архитектурным фреймворкам относятся такие как Zahman Framework, FEAF(Federal Enterprise Architecture Framework), Togaf(The Open Group Architecture Framework), DoDAF и т.п.

Модератор форума, говоря о том что "Java и NET(C#) это параллельные вселенные", имел в виду скорее всего нечто иное чем то чем вы пытаетесь представить его слова в контексте архитектуры. Например, то что Java - это прежде всего мир стандартов.

iscrafm,

Поэтому, хорошему архитектору мало знать одной платформы, чтоб не спускать "танцуйте как хотите".
Конечно же архитектура - это набор принципов и паттернов.
По SAD(software architecture document) и 4+1 view логическая архитектура не привязывается к конкретной платформе. Архитектор создает, например, Component-Connector view где нет указания чем является подсистема или компонент, является ли подсиситема сервисом на основе EJB или WCF - нет абсолютно никакой разницы. Конкретная привязка к платформе может появиться в Implementation View SAD-а чтобы как раз не спускать "танцуйте как хотите".

...
Честно говоря, не очень понял как реализация динамической типизации в языках коррелирует с архитектурой.
Попробую придумать... Допустим мне требуется использовать механизм динамической типизации, например, привести один интерфейс к другому, выполнить проверку типов, инстанцирование в рантайме и т.д. Какая мене разница с архитектурной точки зрения как это делают нижлежащие библиотеки и языки? На абстрактном уровне я знаю что есть механизмы сериализации-десериализации, есть техника Dependency Injection, в конце концов по Adapter/Bridge. Для чего мне с точки зрения архитектуры понимать механизм RTTI конкретного языка?
Ведь понятия DI, сериализации-десериализации никак от этого не изменятся.

iscrafm,
авторКонечно, если под архитектурой понимать общее "бла-бла" типа как в той же "Шаблоны интеграции корпоративных приложений"
Ну там не совсем бла-бла-бла.
Вот, к примеру, беру IBM Message Broker в качестве ESB и вижу что в среде разработки можно выбрать из списка паттерн, описанный в "Шаблоны интеграции корпоративных приложений" и среда сгенерит MessageFlow c набором из компонентов соответствующих message broker-у.

Petro123Но, например, введение ОРМ в Java и DI \ аннотаций очень сильно изменило архитектуру.
Не совсем понимаю что это принципиально изменилось? Даже на стороне Java.
Был Service Locator, стал Inversion Of Control / DI. Появились новые ОО-техники. Но они же на всех платформах используются, не только в Java.
Не было аннотаций, но были xml-файлы маппинга, BMP, CMP. - Изменилась только нижлежащая реализация, появились новые языковые средства, стало удобнее, но это не значит что в приведенном примере архитектурно что то настолько поменялось, что не может быть спроецировано на "устаревший" код или даже на другую платформу.

Выбор между Spring и EJB или каким-либо еще феймворком/библиотекой "(в Java 50 фреймворков и подходов (Архитектуры) под них)" должен делаться на мой взгляд исходя из введенных ограничений и допущений по производительности, надежности, масштабируемости, а не из того что модно/ново/интересно или по каким либо еще субъективным причинам.