CODEWITHSUNDEEP
nservicebussoaesb
Tyler Day
Tyler Day

Reputation: 1718

NServicebus hierarchy and structure

I am just starting out learning NServicebus (and SOA in general) and have a few questions and points I need clarification on regarding how the solution is typically structured and common best practices:

  1. The documentation doesn't really explain what an endpoint is. From what I gather it is a unit of deployment and your service will have 1 or more endpoints. Is this correct?

  2. Is it considered best practice to have one VS solution per Service you are developing? With a project for messages, then a project for each endpoint, and finally a project that is shared with the endpoints containing your domain layer?

  3. From what I read, services are usually comprised of individual components. Can (or should) any component in the service access the same database, or should it be one database per component?

Thanks for any clarification or insight one can offer.

Upvotes: 0

Views: 335

Answers (1)

Sean Farmar
Sean Farmar

Reputation: 2283

I will try and answer your questions the best i can...

I'm not sure about the term "Best Practices" i would consider the term "Best Thinking" or "Paradigm"

Q1: yes, an endpoint is a effectively a deployed process that consumes the messages of it's queue.

It's dose not have to belong to a single "Service" (logical) (In the case of a web endpoint for example), an endpoint can have one or more handlers deployed to it.

Q2: I would go with one solution (and later repo) per logical domain service, Inside a solution I would create a project per message handler, because as you scale you will need to move you handler between endpoints, or to their own endpoint depending on scale. Messages however are contracts, so i would put them in a solution/s maybe split commands and events. You may consider something like nuget to publish your message packages.

Q3: A "Service" is a logical composition of autonomous components, each is a vertical slice of functionality, so they can share the same database, but i would say that only one component has the authority to modify it's own data. I would always try to think what would happen when you need to scale.

Dose this make sense?

Upvotes: 5

Related Questions