Разделение и присвоение имен Microservices

Question

Недавно я начал работу над побочным проектом. Предполагалось, что это виртуальная книга рецептов с возможностями хранения и получения рецептов (CRUD), оценки их и поиска по ним. Это ничего нового, но я хотел создать его как настольное приложение, чтобы узнать больше о базах данных, модульном тестировании, пользовательских интерфейсах и т. Д. Теперь, когда основной домен в значительной степени выполнен (я использую DDD-подход), и я реализовал большинство CRUD-репозиториев, я хочу сделать это немного более расширяемым, разместив основные функции онлайн, поэтому я могу писать несколько бэкэндов (настольное приложение, веб-приложение, web api и т. д.).

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

Возьмите следующие части проекта:

• Core, домен (Заполнители, Сущность, Value Objects, Logic) ->Java
• Постоянство (Даосы Хранилище, множество реализаций Серверных баз данных) - >Java
• Search (Поиск услуги, которые используют запросы SQL на настойчивости БД для поиска) ->Java
• Desktop Application ->JS (Electron) или JavaFX
• Веб-приложение ->Настой или Rails
• Web API (Управление, Rate, Поиск рецептов с использованием REST) ​​->?

Мой первоначальный подход был бы поставить домен ядра, сохранение, поиск и веб-API в одном подпроекта и хозяйничать, что весь стек на Heroku или что-то подобное. Таким образом, мои клиенты могут использовать веб-интерфейс. Настольные и веб-приложения будут разными проектами сами по себе. Приложение Dektop может совместно использовать основной домен, если они оба написаны на Java.

Действительно ли это действительный подход, или я должен разделить первый сервис на более мелкие части? Как вы называете эти услуги?

Answer 1

Эрик Эванс на конференции GOTO 2015 (https://youtu.be/yPvef9R3k-M), и я согласен с ним на 100%, ответил на ваш вопрос. Область Microservice должна быть одним или, возможно, более ограниченным контекстом (-ами). Включая его поддерживающие классы для настойчивости, API REST/HTTP и т. Д. Как я понял, микросервис - это оболочка развертывания через ограниченный контекст с добавлением изоляционных, масштабирующих и устойчивых аспектов. Как вы писали, вы не применяли стратегический дизайн для определения ограниченного контекста. Так что его время проверить, прежде чем разрывать приложение на части.