Максим Кузнецов

Во-первых, слово "не охота" не совместим с уровнем "мастер своего дела". Возможно, потому и начальство кричит... Как правило, когда процесс разработки выстроен и понятен всем заинтересованным лицам, крика значительно меньше, и разработчики появляются тоже в соответствии с планом, не раньше.
Во-вторых, план - это живой постоянно изменяющийся инструмент руководителей, причём с разных сторон. Заказчик/подрядчик/субподрядчик/ещё кто-то. Если план понятный и "живой", постоянно актуализируемый, то кричать никто не будет - времени нет, надо свои задачи всем делать. А вот если план делают "для галочки", то крика всегда много.
В-третьих, распараллелить нельзя только жёстко последовательные задачи. Причина - либо технологическая (нельзя данные залить, пока база не создана), либо ограничения ресурсов (дядя Ваня зальёт данные, когда ему компьютер настроят). Всё остальное решается декомпозицией задач с получением понятных промежуточных результатов. SMART ваше всё.
В-четвёртых, да, план должен быть основан на принятых технических решениях. Иногда эти решения при реализации (и даже позже!) признаются неверными, и приходится перепроектировать систему, и тогда нужно менять план работ. Это нормально и даже неизбежно, особенно для сложных систем. Но тут уже в плане нужно предусматривать работы по управлению рисками, а в самой системе надо предусматривать такие решения, которые позволят изолировать проблемные места и не допустить, чтобы ошибки проектирования или изменения требований не привели к слишком высоким затратам.
Итого, что крик стоит, и что разработчики ждут - это прямые последствия ошибок планирования и отношения к плану. Не ошибается тот, кто ничего не делает. Вы хорошо знаете аналитику, поэтому с детализацией требований вопросов нет. Но надо развиваться в технологиях, в особенностях процессов разработки, в особенностях управления проектом. Тогда планы будут более реалистичными. Но ещё надо перестать смотреть на план как одну из стадий "водопада". План меняется всё время, планирование продолжается от начала и до конца проекта минимум, а чаще - в течение всего жизненного цикла системы. Тогда и нервы у всех участников работ лишний раз никто не полоскает.
И ещё про детализацию. Задача длительностью 4 часа сильно отличается от задачи длительностью 5 часов. Потому что первую задачу можно выполнить, не отвлекаясь, один раз "войдя в творческий поток". А задачу длиннее 4 часов исполнитель без отвлечений не выполнит никогда (в смысле 95% случаев, остальные 5% - тоже с разрывом "потока" и исключительно на своей самодисциплине). Итого, 5-часовая задача сразу превращается в 6-8 часовую. Фокус-фактор выше 65% не бывает. Так что декомпозируйте задачи так, чтобы они реально были исполнимыми в указанные сроки.

По-хорошему нужен движок для моделирования и контроля бизнес-процессов. С учётом их версионирования. На Java в своё время пользовался Alfresco Activity ( https://www.alfresco.com/products/business-process... ). Есть comunity-редакция. В .NET есть WWF ( https://msdn.microsoft.com/en-us/library/jj684582.aspx ), но я сам им не пользовался.

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

А дальше - полёт фантазии. Кроме указанных вариантов можно рассмотреть ещё несколько решений. Например, по расписанию в БД заполнять некоторую таблицу-"витрину" нужного формата, из которой уже напрямую отдавать данные куда угодно. Такое решение удобно, если построение "витрины" происходит долго из-за объёмов данных. Заранее готовите данные и потом моментально отдаёте.

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

Architecture Skills Framework
Грубый перевод таблиц был здесь: Что должен знать и уметь архитектор

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

Некоторые из общеизвестных Вы перечислили. Ещё можно посмотреть, например, здесь: Catalog of Patterns of Enterprise Application Arch.... Возможно, многие из этих паттернов Вы тоже используете, только не называли их в своём вопросе. Но со временем, возможно, у Вас накопятся собственные наработки.

Я бы создал класс AbstractClass, чтобы CommonClass и ConcreteClass1 наследовались от него. ConcreteClass2 должен наследоваться от ConcreteClass1. В AbstractClass вынес бы из CommonClass те члены, которые должны быть общими для всех классов. Всё.

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

Сбои бывают разные. Крах процесса, крах ОС, отказы оборудования. Тут нужен определённый анализ угроз для Вашей системы. Мониторинг должен отрабатывать все критические ситуации.

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

Всё просто. Делаете класс для объекта А. Затем - класс для объекта Б. В классе Б объявляете поле a типа А. В классе А - поле b типа Б. Изначально при создании экземпляра класса А ссылка на объект класса Б в поле b будет пустой (null). При создании экземпляра класса Б его поле a со ссылкой на объект класса А тоже будет содержать пустое значение null. Пусть для объекта А задан метод Link, который в качестве параметра получает ссылку на объект класса Б. Внутри этого метода можно присвоить полю A.b указанную ссылку на объект Б, а затем полю Б.а можно присвоить ссылку на объект А, метод Link которого был вызван.

Объект Б можно создавать в конструкторе объекта А, тогда там же задавайте значения полям.

Аналогично, можно в классе А задать поле типа массив объектов Б. При внесении нового объекта в массив можно задавать ссылку на А в поле Б.a.

Класс "Заказ" может иметь указатель на экземпляр класса "Заказчик" (в случае ООП это будет ссылка на объект). Каждый "Заказчик" может иметь список "Заказов" (массив указателей на сделанные им заказы).

"Заказ" должен быть композицией нескольких составных частей - "работ", каждая из которых должна иметь указатель на исполнителя, а "Исполнитель" может иметь массив указателей на "работы", которые ему назначены.

При таком исполнении не нужно смотреть все заказы, чтобы выявить относящиеся к данному заказчику. И не нужно отдельно выбирать работы для исполнителя. Вы же работаете с классами, а не с таблицами БД: тут логика несколько иная. Реляционные БД основаны на теории множеств, а не на теории взаимосвязанных объектов.

Вы не смотрели класс TransactionScope? https://msdn.microsoft.com/ru-ru/library/system.tr...(v=vs.110).aspx

Мартин Фаулер. Архитектура корпоративных программных приложений. - Пер. с англ. — М.: Издательский дом "Вильяме", 2006.

Руководство Microsoft по проектированию архитектуры приложений. 2-е издание. - Microsoft Patterns & Practices Team, 2010.

Анализ требований и создание архитектуры решений на основе Microsoft .NET - Microsoft, Русская редакция, 2004.

Sparx Enterprise Architect

Ищите реализацию метода Change(e); Этот метод производит изменения и сохраняет результат.

Боюсь, не смогу дать чёткого решения проблемы, слишком мало данных. Но может, мой опыт пригодится.

В своё время делал комплексную систему безопасности. Это был коробочный продукт, при мне выпустили 4 версии. В системе требовалось привязать кучу оборудования: видеокамеры, считыватели, СКУД, сканеры документов и прочую снедь. Проблему решили просто: были созданы унифицированные абстрактные классы под каждый класс оборудования: для сканеров (получение сканов документов), под СКУД (информация о проходах), под считыватели (события чтения карт, билетов, биометрии), под камеры (получение видео и фотоизображений), под системы распознавания изображений... Абстрактные классы имели абстрактные методы для получения входных данных и реализацию методов дальнейшей обработки информации, соответствующих данному классу устройств. Реализация конкретных классов для конкретных моделей устройств была вытащена в плагины, которые подцеплялись динамически.

Мы всегда знали, какие устройства поддерживаем, и делали под них соответствующие плагины. Интерфейсы и абстрактные классы переделывать было не нужно, они не менялись. Допустим, было несколько считывателей: магнитные карты нескольких типов, билеты со штрих-кодом, отпечатки пальцев... Но они все были нужны, чтобы выполнить одну функцию: опознать владельца предъявленного идентификатора. Поэтому реализация плагина была для каждого устройства своя, а вот интерфейс его взаимодействия с ядром системы - один на все устройства.