Домен-событийно-управляемая архитектура - PullRequest
2 голосов
/ 29 января 2011

Я начинаю проект веб-приложения на Java и провожу некоторые исследования по выбору архитектуры.

Он будет иметь n сервисов (Биллинг, Отчетность, Продажи, CRM и т. Д.), Которые в зависимости от сервиса могут работать или не работать как автономное веб-приложение.

Мне действительно нравится подход, управляемый доменами и событиями. Дело в том, что я никогда не делал такой большой проект раньше, и я был бы очень признателен, если бы выслушали некоторые мысли и советы о том, куда идти.

С архитектурой, управляемой доменом, по событиям, мои главные сомнения следующие:

  • Если мне нужны данные из другого сервиса, правильно ли создавать для него веб-сервис и получать от него доступ ко всем данным? Я буду генерировать более глубокую связь здесь, и это то, чего я хочу избежать. Какие еще подходы есть?

  • Как осуществляется настойчивость? Есть ли у каждого сервиса своя БД? Нет связи между базами данных сервисов?

  • Что делать, если служба не работает? Он потеряет все сообщения и, следовательно, не сможет предпринять соответствующие действия, верно? Есть обходные пути?

  • Что делать, если ActiveMQ выходит из строя?

Заранее большое спасибо!

1 Ответ

3 голосов
/ 29 января 2011

Если мне нужны данные из другого сервиса, правильно ли создавать для него веб-сервис и получать от него доступ ко всем данным?

Да.

Я хотел бы создать здесь более глубокую связь, и это то, чего я хочу избежать.

Ложные. Вы должны объяснить, какая связь, по вашему мнению, произойдет здесь.

Какие есть еще варианты?

Сервис-ориентированные архитектуры делают это постоянно. Альтернативы больше тесно связаны.

Как делается настойчивость? Есть ли у каждого сервиса своя БД?

Да. Услуги стоят в одиночестве. Часто службы являются частью больших упакованных приложений.

Нет связи между базами данных служб?

Правильно.

Что делать, если служба не работает?

Облом. Запрашивает резервные копии в очередях, пока вы не перезапустите службу.

Он потеряет все сообщения и, следовательно, не сможет предпринять соответствующие действия, верно? Есть обходные пути?

Ложные. Совершенно неверно. Вы можете использовать постоянные, надежные очереди сообщений.

Что делать, если ActiveMQ выходит из строя?

Тогда мир, каким мы его знаем, заканчивается. Что вы подразумеваете под «провал»? Это довольно слабосвязанная система, которая позволяет решать и решать множество проблем.

...