Нужно создать архитектуру веб сервиса по готовому ТЗ по стандарту SOLID .
под этим, главным образом, подразумевается декомпозиция программы на подсистемы (функциональные модули, сервисы, слои, подпрограммы) и организация их взаимодействия друг с другом и внешним миром. Максимальная независимость и изолированность модулей друг от друга.
Основные требования к архитектуре
Масштабируемость
возможность расширять систему и увеличивать ее производительность, за счет добавления новых модулей.
Ремонтопригодность
изменение одного модуля не требует изменения других модулей
Заменимость модулей
модуль легко заменить на другой
Возможность тестирования
модуль можно отсоединить от всех остальных и протестировать / починить
Переиспользование
модуль может быть переиспользован в других программах и другом окружении
Сопровождаемость
разбитую на модули программу легче понимать и сопровождать
Эффективность системы. В первую очередь программа, конечно же, должна решать поставленные задачи и хорошо выполнять свои функции, причем в различных условиях. Сюда можно отнести такие характеристики, как надежность, безопасность, производительность, способность справляться с увеличением нагрузки (масштабируемость) и т.п.
Гибкость системы. Любое приложение приходится менять со временем — изменяются требования, добавляются новые. Чем быстрее и удобнее можно внести изменения в существующий функционал, чем меньше проблем и ошибок это вызовет — тем гибче и конкурентоспособнее система. .
Расширяемость системы. Возможность добавлять в систему новые сущности и функции, не нарушая ее основной структуры. Архитектура должна позволять легко наращивать дополнительный функционал по мере необходимости. Причем так, чтобы внесение наиболее вероятных изменений требовало наименьших усилии.
важное условие
Должна быть возможность расширить/изменить поведение системы без изменения/переписывания уже существующих частей системы.
Масштабируемость процесса разработки. Возможность сократить срок разработки за счёт добавления к проекту новых людей. Архитектура должна позволять распараллелить процесс разработки, так чтобы множество людей могли работать над программой одновременно.
Тестируемость. Код, который легче тестировать, будет содержать меньше ошибок и надежнее работать. Руководствуемся критериием легкой тестируемости при делении на блоки.
Сопровождаемость. Над программой, как правило, работает множество людей — одни уходят, приходят новые. После написания сопровождать программу тоже, как правило, приходится людям, не участвовавшем в ее разработке. Поэтому хорошая архитектура должна давать возможность относительно легко и быстро разобраться в системе новым людям.
Возможность повторного использования. Систему желательно проектировать так, чтобы ее фрагменты можно было повторно использовать в других системах.
поэтому нужно создать модульную иерархически архитектуру из микросервисов
сначала систему разбить на крупные функциональные модули/подсистемы, описывающие ее работу в самом общем виде. Затем, полученные модули, анализируются более детально и, в свою очередь, делятся на под-модули либо на объекты. Основная задача разбивается на составляющие ее подзадачи, которые могут решаться/выполняться независимо друг от друга. Каждый модуль должен отвечать за решение какой-то подзадачи и выполнять соответствующую ей функцию. Помимо функционального назначения модуль характеризуется также набором данных, необходимых ему для выполнения его функции, то есть:
Модуль = Функция + Данные, необходимые для ее выполнения.
Причем желательно, чтобы свою функцию модуль мог выполнить самостоятельно, без помощи остальных модулей, лишь на основе своих входящих данных.
Критерии для выделения функций в отдельные модули
1.Самым же главным критерием качества декомпозиции является то, насколько модули сфокусированы на решение своих задач и независимы. Обычно это формулируют следующим образом: "Модули, полученные в результате декомпозиции, должны быть максимально сопряженны внутри и минимально связанны друг с другом.

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

3.является принцип единственной ответственности (Single Responsibility Principle — первый из пяти принципов SOLID), согласно которому любой объект/модуль должен иметь лишь одну обязанность и соответственно не должно быть больше одной причины для его изменения.

4.слабая связанность, означает что модули, на которые разбивается система, должны быть, по возможности, независимы или слабо связанны друг с другом. Они должны иметь возможность взаимодействовать, но при этом как можно меньше знать друг о друге (принцип минимального знания).
Это значит, что при правильном проектировании, при изменении одного модуля, не придется править другие или эти изменения будут минимальными. Чем слабее связанность, тем легче писать/понимать/расширять/чинить программу.

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

6. Делая декомпозицию системы желательно проверять ее качество задавая себе вопросы: "Какую функцию выполняет каждый модуль?", “Насколько модули легко тестировать?”, “Возможно ли использовать модули самостоятельно или в другом окружении?”, “Как сильно изменения в одном модуле отразятся на остальных?”
В первую очередь следует, конечно же, стремиться к тому, чтобы модули были предельно автономны.
Модули должны быть друг для друга "черными ящиками" (инкапсуляция). Это означает, что один модуль не должен «лезть» внутрь другого модуля и что либо знать о его внутренней структуре. Объекты одной подсистемы не должны обращаться напрямую к объектам другой подсистемы
Модули/подсистемы должны взаимодействовать друг с другом лишь посредством интерфейсов (то есть, абстракций, не зависящих от деталей реализации) Соответственно каждый модуль должен иметь четко определенный интерфейс или интерфейсы для взаимодействия с другими модулями.
При проектировании модуля должны быть определены следующие ключевые вещи:
что модуль делает, какую функцию выполняет,что модулю нужно от его окружения, то есть с какими объектами/модулями ему придется иметь дело и как он это будет получать.
Считается, что хорошо спроектированные модули должны обладать следующими свойствами:
функциональная целостность и завершенность — каждый модуль реализует одну функцию, но реализует хорошо и полностью; модуль самостоятельно (без помощи дополнительных средств) выполняет полный набор операций для реализации своей функции.
один вход и один выход — на входе программный модуль получает определенный набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, т.е. реализуется стандартный принцип IPO — вход–процесс–выход;
логическая независимость — результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;
слабые информационные связи с другими модулями — обмен информацией между модулями должен быть по возможности минимизирован.

В соответствии с выше изложенным нужно сделать:

1. Разбить задачу на отдельные независимые блоки,
2. каждый блок будет выполняться отдельным программистом. Он должен понимать какие входные данные он получает и что должно получиться в результате работы данного блока. Какие данные должны получится в результате работы блока.
3. Каждый блок должен быть выполнен в виде законченного модуля со своим API , из которых потом будет собираться сервис.
4. Время разработки каждого блока не более 7 дней , одним программистом.
5. Обозначить каким образом , проверять работоспособность блока. Какие тесты он должен пройти.
В данном сервисе я вижу вариант взаимодействия между модулями не каждого с каждым, а работу через общую базу данных, все модули проектируются независимыми друг от друга клиентами, использующими данные этой базы или выполняющими обработку содержащейся там информации. Синхронизация происходит тоже через общую базу.
Реализация этой идеи позволяет модулям-клиентам общаться друг с другом через посредника и при этом ничего друг о друге не знать
Результат нужен в виде блок схемы со стрелками взаимодействия и текстовый файл с описанием назначения,взимодействия , входными и выходными параметрами и способом проверки работы модуля.