I am trying to further my understanding of DDD. More specifically, how to handle domain events via a message bus for asynchronous processing.
Lets say I have some architecture ->
_____________________
| |
| Client |
|_____________________|
|
__________|__________
| |
| Application Service |
|_____________________|
|
__________|__________
| |
| Domain |
|_____________________|
When my domain raises some domain event, how do I get that event
to a messaging service such as RabbitMQ?
My first thought is to inject a message bus service, IMessageBus,
that knows how to send the events to RabbitMQ. The service would be used
by domain event handlers to dispatch the event to the bus.
But then I thought, now my domain has to know how to handle its own events.
Can someone shed some light on the matter?
The Service Bus is part of the infrastructure, however the application services know about it (as an abstraction). It's ok to inject the bus into the app service, because the app service doesn't contain domain logic but acts as the coordinator and host of a business use case.
But then I thought, now my domain has to know how to handle its own events.
Yeah, but the bus only deliver the messages, the message handlers are basically application services.
Rabbit and others are an implementation details, your app handlers should be invoked by the service bus (which should abstract the actual messaging process).
This question is analogous to "how does your domain communicate with an external system (other than for data persistence)"?
A service bus is no different from a physical sensor or other external piece of hardware. One typically represents those physical things in code as an object that abstracts the physical concept. They are outside the problem domain (PD) and can be considered System Integration (SI) objects.
If your domain needs to communicate with an external system, it simply makes a call on its equivalent SI object. Equally, an SI object can call on your domain.
Note: this answer assumes your domain is not anemic.
Related
Would it be possible to map a url to point to an instance of the azure event hub?
Could I add a CNAME to a domain and point to sb://.servicebus.windows.net
I think that A Records map to a static IP address, and as there doesn't seem to be an option to configure that in Azure I don't think that would work, but would it be possible so that all requests to something like https://serivcebus.mydomain.com could be pushed to the event hub?
We have a requirement to embed the connection to the event hub into our SDK which will be pushed out to a huge volume of customer devices, which may or may not be upgraded if we change. In order to support us potentially changing the technology behind the end point being posted to we wanted to map it to our own domain, allowing us, if needed, to swap out the back end technology without changing the code on clients devices.
There is potential to do this via our own Gateway API but then that may bottleneck the benefits gained from using the service bus itself.
We ended up putting a web app infront of the event hub and it basically just passed the messages through. The CName obviously worked fine on that.
I currently designing a solution for communication between a Charge Point for Electrical Vehicles and the backoffice. the ChargePoint are connected to the Network of the Telephone company and the backoffice is hosted on Azure. The Chargepoint don't have a public IP-address. In order to send messagese from the backoffice to the ChargePoint we want to implement Azure Service Bus (ASB) Relay. The ChargePoint OS is embeded Linux and Azure is Microsoft. The ASB Relay only works with WCF bindings. I found out that mono supports WCF but cann't find if it supports httpRelayBinding?
what kind of communication are you looking for between the device and service? If you need Relay like two-way or one-way synchronous RPC communication then you could use a simple http client to call into the service, a sample for this is here: http://code.msdn.microsoft.com/windowsazure/Relayed-Messaging-Bindings-a6477ba0
Also if you are looking for different patterns of communication such a brokered messaging where you can send/receive messages w/ data then you can consider using Service Bus Queues and Topics. I recently covered some of these usage scenarios in my session at TechEd: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B336
I have a WCF Service that I want to consume from my application. In following DDD I understanding that the semantics of connecting and consuming this service should be done through a Service Agent (Infrastructure Layer).
I am happy with this however it makes me ask the following questions;
Should the Service Agent Interface be defined in the Domain Layer?
Should a repository be defined that wraps this Service Agent?
Thanks
Service Agent usage should be inside infrastructure layer. SA interface doesn't belong to domain layer since it's not part of the business domain - it has strictly technical meaning (business experts probably didn't even heard of it).
Yes, repository is the most natural wrapper around WCF Service if it is dealing with fetching/storing data. If it is dealing with business operations domain service would be better choice.
I have a question that is confusing me what are the differences between the types of service bus, the brokered messaging and the relayed messaging? I am not looking for it from the development perspective but I want to understand more the concept and the differences between them.
Thank you.
Service Bus Relay and Service Bus Brokered Messaging are both mechanisms for developing distributed and hybrid applications. However, they target different development and access patterns.
Service Bus (SB) Relay provides a simple & secure way to do service remoting, i.e., it enables you to securely expose a service hosted on a private cloud to external clients. As is the case with service remoting scenarios, clients explicitly invoke the methods exposed by the "Relayed" service. The primary advantage of SB Relay is that the service can be exposed without requiring any changes to your Firewall settings or any intrusive changes to your corporate network infrastructure.
SB Brokered Messaging on the other hand provides a durable messaging platform with components such as Queues, Topics and Subscriptions. These can be used to implement complex patterns such as publish-subscribe and temporal decoupling between different parts of your application. Since the brokered messaging infrastructure can reliably store the messages, the senders and the receivers do not have to be online at the same time, or do not have to process the messages at the same pace.
Relayed messaging is thus appropriate for scenarios where you have a service that you want to expose to external clients. Clients interact with the "Relayed" service in the same manner that they would if they were on the local network, except that they access it via the SB Relay endpoint. Since this is a service remoting scenario, response is immediate subject to network latency. However, if for whatever reason the service is unavailable at that moment, the client's request will always fail.
In the case of brokered messaging, since the send & receive operations are decoupled, the sender can continue to send messages that are reliably stored on the service regardless of whether the receiver is online or not. However, the tradeoff for this resiliency is that the request will be processed subject to receiver's ability to retrieve and process the message.
I think the main difference is the synchronous vs asynchronous nature of connectivity.
Where relay is mostly a firewall friendly way to expose web services to the public world (even behind firewalls, NAT devices, etc), messaging is more of a way to exchange in an asynchronous way messages over queues and topics. (look at it as the next version MSMQ with cloud support :))
Everything depends on the scenario, but if you are looking for
- Routing (pub/sub)
- Loose coupling sender & receiver
- Load leveling
Then you should definitely go for messaging.
If you want to make your service easily reachable for the outside world, relay service is your friend.
From Azure's site:
Relay
The Service Bus Relay service enables you to build hybrid applications
that run in both a Windows Azure datacenter and your own on-premises
enterprise environment. The Service Bus relay facilitates this by
enabling you to securely expose Windows Communication Foundation (WCF)
services that reside within a corporate enterprise network to the
public cloud, without having to open up a firewall connection or
requiring intrusive changes to a corporate network infrastructure.
Relay also handle load balancing for you (you can have multiple applications listen at the same endpoint for the majority of the bindings).
Brokered Messaging
The second messaging solution, new in the latest release of the
Service Bus, enables “brokered” messaging capabilities. These can be
thought of as asynchronous, or decoupled messaging features that
support publish-subscribe, temporal decoupling, and load balancing
scenarios using the Service Bus messaging infrastructure. Decoupled
communication has many advantages; for example, clients and servers
can connect as needed and perform their operations in an asynchronous
fashion.
Brokered messaging includes Queues and Topics / Subscriptions that allow you to send / receive messages asynchronously.
The main difference is that for relay, you have applications listening at an endpoint. When you send a message, the application processes that message when it is received. For brokered messaging, the message is stored when it is received by the client and can be processed at any time.
I’m designing a backend that allows users to establish a TCP socket with it and send/receive stuff along this socket (using a pseudo-protocol I’ve made up) in real-time.
It has to be scalable – i.e. architected on a cloud host. Currently I’m evaluating Windows Azure.
To achieve scalability the application will run on several Web Role Instances. Meaning the users’ TCP sockets will be split across several instances (via a load balancer).
This backend is an event-driven application – when a user sends something to it the message should be passed on to all other connected users.
This means there must be a reliable way to send messages from one Web Role Instance to all other Web Role Instances. As far as I understand, this is what inter-role communication refers to.
Using Service Bus, is it possible for all Web Role Instances to subscribe to a Topic and publish messages to it? Thus implementing the event-driven requirements of my distributed application?
(If not then I’ve misunderstood what this article is about: http://windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/)
I wanted to find this out before delving too deep into learning C#, .NET and Windows Azure development.
Thank you for your help.
Yes, using the service bus, all the web roles could send messages to a single topic and each role could have unique individual subscriptions to that topic, such that they all receive the messages sent.
Clemens Vaster has implemented an extension to SignalR using the service bus. It is possible that SignalR + the Service Bus may meet the needs of your project, including the TCP socket implementation.
http://vasters.com/clemensv/2012/02/13/SignalR+Powered+By+Service+Bus.aspx