В прошлой своей статье я составил приблизительный план того, как собираюсь писать приложение, реализующее распределённый кеш на Apache Ignite. И в ней уже обозначил основные компоненты приложения, разделив их по признаку ответственности (как сказал бы Боб Мартин) или другими словами по тому, какую функцию они будут выполнять. Такими компонентами будут:
1. Загрузчик датасета.
Он будет скачивать датасет на локальный диск и разархивировать его (если будет принято решение использовать заархивированный датасет).
2. Парсер датасета.
Он будет парсить загруженный датасет, мапить распарсенные данные в модели и отправлять данные в кеш.
3. Менеджер загруженных файлов.
Он будет различные операции с файлами. Например, архивирование или удаление.
4. Сервис, отвечающий за взаимодействие с кешем Ignite: положить даные в кеш, достать данные из кеша. Иногда сервис, отвечающий за взаимодействие с хранилищем данных, называют репозиторием. Возможно, у меня он будет называться так же.
5. И, конечно, нам понадобится главный компонент, который будет объединять все остальные компоненты в одно приложение и управлять ими (запускать, останавливать и т.д.).
Теперь надо всё это красиво зарисовать в виде диаграммы, которую мы громко назовём архитектурной схемой. Мне нравится рисовать такие штуки на draw.io.
Через несколько часов труда (на самом деле меньше) и с десяток порванных набросков (на самом деле больше), у меня получилась вот такая архитектурная схема:
Что на ней изображено:
Data server - место, откуда мы будем скачивать датасет.
Apache Ignite Service Grid - платформа, которая будет запускать на исполнение наш сервис.
Apache Ignite Data Grid - собственно, сам кеш на базе Apache Ignite.
Logging - подключим фреймворк, который будет отвечать за логирование событий в нашем приложении.
Application - главный компонент приложения, который будет управлять всеми остальными компонентами.
Downloader - загрузчик датасета.
FileManager - управление загруженными файлами.
FileParser - парсинг загруженных файлов.
ActivityRepository - будет хранить в кеше данные об активности приложения.
DataRepository - будет хранить в кеше распарсенные данные.
PropertyUtility - утилитные методы для работы с настройками приложения. Какие это будут настройки - придумаем по ходу пьессы. Но они будут конфигурируемы извне приложения. Зачем так сложно? Сейчас всем, что связано с CI/CD, занимаются, как правило, инженеры DevOps. Для них может оказаться совсем неочевидным, где внутри нашего приложения нужно искать захардкоженные настройки, как их правильно поменять, чтобы приложение после этого скомпилировалось и собралось в исполняемый файл. Поэтому выносим все настройки наружу, в файл, который будет находиться отдельно от нашего скомпилированного приложения.
DateTimeUtility - работа с датами и временем. Если он нам не пригодится, мы от него откажемся позже. А пока - пусть будет.
Т.к. мы будем писать "самое настоящее интерпрайз-приложение", то для него мы заведём репозиторий на гитхаб.
