иерархия и структура

Question

Я только начинал учиться NServicebus (и SOA в целом), и есть несколько вопросов, и пункты мне нужно разъяснение по поводу, как решение, как правило, структурированы и общие лучшие практики NServicebus:

1. В документации на самом деле не объясняется, что такое конечная точка. Из того, что я нахожу, это единица развертывания , и ваш сервис будет иметь 1 или более конечных точек. Это верно?

2. Считается ли наилучшей практикой иметь одно решение VS на одну услугу, которую вы разрабатываете? С проектом для сообщений, затем проектом для каждой конечной точки и, наконец, проектом, который совместно используется конечными точками, содержащими ваш уровень домена?

3. Из того, что я читал, услуги обычно состоят из отдельных компонентов. Может (или должен) любой компонент службы обращаться к одной базе данных или должен быть одной базой данных для каждого компонента?

Благодарим за любые разъяснения или понимание, которые вы можете предложить.

Answer 1

Я постараюсь ответить на ваши вопросы лучшее, что я могу ...

Я не уверен по поводу термина «Best Practices» я хотел бы рассмотреть термин «Лучшее мышление» или «Парадигма»

Q1: Да, конечная точка - эффективно развернутый процесс, который потребляет сообщения своей очереди.

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

Q2: Я бы пошел с одним решением (и более поздним репо) в службу логического домена. Внутри решения я бы создал проект для обработчика сообщений, потому что, когда вы масштабируете, вам нужно будет переместить обработчик между конечными точками или их конечная точка зависит от масштаба. Сообщения, однако, являются контрактами, поэтому я бы поставил их в решение/с, возможно, разделить команды и события. Вы можете рассмотреть что-то вроде nuget, чтобы опубликовать ваши пакеты сообщений.

Q3: «Сервис» - это логический состав автономных компонентов, каждый из которых представляет собой вертикальный срез функциональности, поэтому они могут совместно использовать одну и ту же базу данных, но я бы сказал, что только один компонент имеет право изменять свои собственные данные , Я всегда старался думать, что произойдет, когда вам нужно масштабироваться.

Доза это имеет смысл?