It's not that simple, and of course "it depends":
I can't remember where, but I think I remember reading Roger Johansson write something along the lines of "Don't queue messages using an enterprise queue if your actors will be the only consumers".
what this is referring to, is the super high cost of serialising a message via an enterprise bus (not in memory), that in order to make "durable" has to first write to persistent storage, typically disk, and get confirmation of successful write before continuing. (plus other costs, serialisation, deserialisation, network latency, packet re-combination, etc etc) This can be up to 100 000 times slower (random really huge number, but you get my point) than class A calling method of class B, or class A using Mediator to class B. In process method calls are guaranteed to be ACID, and while they're not durable, if you 're 100 000 faster, then replaying the entire message chain if failed is a responsiblity of the parent, typically with it's own try catch. so system crashes, so what (I laugh in the face of system failures mwaaa! "mini me" strokes cat) , when it starts it goes, oh, so-and-so saga didn't complete, replay it, and all it's child messages get replayed.
The key lesson here is make the entry point message to the micro service "durable" and for all internal messages make them fast as heck, and idempotent. (really rough paraphrasing here)
TLDR; entry point to micro-service should be your service processing a message picked up from some durable message bus. Internally, consider using patterns like an in memory bus, or an actor framework, eg libraries like Akka.net, TPL DataFlow etc and as far as possible, designs that don't require durability anywhere other than at the incoming and outgoing edges of the main message processing pipeline.
- In memory message bus typically does not "queue" work, i.e. Gregory Young's FakeBus linked to above just starts the work in a background thread, so you have to worry about concurrency.
- Concurrency frameworks, like Akka.net and TPL DataFlow give you high and low level tools respectively for managing work (thread) concurrency. Eliminating a large portion of software engineering problems. Akka.net focuses on higher abstractions around the actor pattern, wheras TPL DataFlow provides low level thread "Pipeline" concurrency management. I highly recommend you complete introductory training on both, before you choose either tool.
If you work on your own, are highly detailed, or writing a library, then possibly consider TPD DataFlow. If you're working in a large team, and building mainly business applications, consider Akka.net or similar actor frameworks.
- use to send the big Domain Commands or events. e.g. InvoiceCreated, PaymentMade
- use at entry and exit of micro services
- as described further up, use to simplify code. In my experience it makes code less brittle, and easier to refactor and easier to read (scan) quickly.
- typically it makes DI a lot cleaner, without having to have such huge complex dependencies injected.
- does not make messages durable, does not do anything for concurrency
In memory Bus
- high speed way of decoupling components
- Use for handling private, internal messages between components of the service.
- as the service grows, a service might become a collaboration of micro services. only use an in memory bus to communicate between microservices when there is a parent that can supervise any long running sagas. Typically the durability of the entire saga might be managed by the parent as a result of responding to a durable "message bus" message.
Finally, since I haven't yet answered the OP's question -> "Is it appropriate to use an InMemory Bus for a single Microservice (for domain events) and a durable Message bus for integration events (between Microsservices)?"
I'd say... yes, spot on.
Hope this helps?