1. Monolith
1.1. Pros
1.1.1. Нету накладных расходов на взаимодействие с др. App
1.1.2. Одна база
1.1.3. Быстрая разработка
1.1.4. Вертикальное масштабирование
1.2. Cons
1.2.1. Хрупкость
1.2.1.1. Внедрить Unit тесты
1.2.1.1.1. Обучить
1.2.1.1.2. Не пропускать PR без тестов
1.2.2. Придется часто проводить тестирование т.к. не понятно, что может сломаться
1.2.2.1. Нужны QAs
1.2.3. Сложно дорабатывать и поддерживать (много информации)
1.2.3.1. Документация
1.2.4. Сложно разрабатывать, если команда большая
1.2.4.1. Разбить на модули
1.2.4.1.1. Можно, но сложно т.к. требует проработанную архитектуру
1.2.5. Проверка PR будет занимать много времени
1.2.5.1. Внедрить инструмент
1.2.5.1.1. Кто?
1.2.5.1.2. Когда?
1.2.5.1.3. Какой?
1.2.5.2. Разработать стандарт
1.2.5.2.1. Кто?
1.2.5.2.2. Когда?
2. Micro Services
2.1. Pros
2.1.1. Высокая отказоустойчивость
2.1.2. Гибкость
2.1.3. Легко разобраться в сервисе
2.1.4. Горизонтальное масштабирование
2.1.5. Масштабирование команд
2.2. Cons
2.2.1. Сообщение между самими сервисами сложное
2.2.1.1. Мы готовы уйти от пакетов?
2.2.1.1.1. RabbitMq
2.2.1.1.2. Http + Libs
2.2.2. Рост числа сервисов также влечет за собой и рост числа баз данных
2.2.2.1. Транзакция?
2.2.2.1.1. Можно, но сложно
2.2.3. Хуже подходят для использования внутри отдельных организаций
2.2.3.1. Архитектурный документ
2.2.3.2. RFCs
2.2.4. Логи
2.2.4.1. Подключить доп.библиотеки
3. Architecture
3.1. Good Architecture
3.1.1. Гибкость системы
3.1.2. Расширяемость системы YAGNI, SOLID
3.1.3. Масштабируемость процесса разработки.
3.1.4. Тестируемость.
3.2. Bad Architecture
3.2.1. Жесткость, Rigidity
3.2.2. Хрупкость, Fragility
3.2.3. Неподвижность, Immobility
4. Module Architecture
4.1. Benefits
4.1.1. Масштабируемость (Scalability)
4.1.2. Ремонтопригодность (Maintainability)
4.1.3. Заменимость модулей (Swappability)
4.1.4. Возможность тестирования (Unit Testing)
4.1.5. Переиспользование (Reusability)
4.1.6. Сопровождаемость (Maintenance)
4.2. Модули должны обладать следующими свойствами
4.2.1. Функциональная целостность и завершенность
4.2.2. Один вход и один выход
4.2.3. Логическая независимость
4.2.4. Слабые информационные связи с другими модулями
5. Tech Stack
5.1. Back-End
5.1.1. ASP.NET 5 Web API
5.1.2. EF
5.1.2.1. Работаем только через миграции
5.1.2.1.1. Как быть с процедурами Export и Import
5.1.2.1.2. Как же процедуры?
5.1.2.1.3. Как же SQL Jobs
5.1.3. Swagger
5.1.4. Fluentvalidation
5.1.5. Serilog
5.1.6. OData
5.1.6.1. Изменить подход
5.1.6.1.1. Что не так
5.1.7. HangFire
5.2. Front-End
5.2.1. Angular 11+
5.2.2. State Manager
5.2.3. UIKit
6. Architectures
6.1. V1
6.1.1. Делаем 3 микросервиса(EMP, TimeSheet, Retain)
6.1.1.1. Общаемся через RabbitMq или Http
6.2. V2
6.2.1. Retein отдельный сервис, а EMP и TimeSheet монолит
6.2.1.1. Общаемся через RabbitMq или Http
6.3. V3
6.3.1. Сливаем все в один монолит
6.3.1.1. Back-end
6.3.1.1.1. Разбиваем на проекты внутри Solution
6.3.1.2. Front-end
6.3.1.2.1. Разбиваем на модули
6.3.1.2.2. Разбиваем на State
6.3.1.2.3. Внедрение доп.технологии для оптимизации клиента
6.3.1.3. New TFS Collection
6.3.1.3.1. GIT Flow
6.3.1.3.2. CI/CD
6.3.1.3.3. Board
6.3.1.3.4. Это нам надо?