Domain Events

fabiovip2019 · 2020-08-07 17:59:38

Hi Ab, I am looking to implement domain events to communicate aggregates out of context. I'm thinking of doing this with mormot but I have no idea how I can do it. I don't know if I use Mormot's two-step verification or if I create a specialized handler. What do you recommend me on the subject?

ab · 2020-08-07 19:04:47

I usually use interface callbacks to communicate domain events.
The clients register to to a given service event provider, and provide a callback interface.
In this callback interface, each method is an event, and the method parameters are the event details/context.
Using a publish/subscribe mechanism, and WebSockets, it is a good way to implement the logic with minimal code, and a strong process.

In proper DDD, you are likely not to publish aggregates within events, but only some part of them (value objects), as events parameters. Because each bounded context will have its own kind of aggregate.

Check the documentation about interface-based services.

fabiovip2019 · 2020-08-10 12:49:52

Hi Ab, I had also thought in this way, with websockets but I thought it would not be the correct one, this way the publisher and the consumer, in some cases, will be inside the same server. Do you think this is a problem? I see that with your tip I can publish events instantly and instant subscribers consume those events, correct? If I want to use an event store the best way would be to use TSQLRecord directly, or consider a domain event as an aggregate and use MOrmotDDD. What do you think?

ab · 2020-08-10 13:05:22

Publish/subscribe within the same process will use direct execution, so it will be very fast.

If you use an event store, then you could indeed define them as TSQLRecord and send them as parameters to the publish/subscribe methods.
But events TSQLRecord won't be your Aggregate, I guess, in DDD terms. Aggregates map the state of a really within a given bounded context.

fabiovip2019 · 2020-08-10 14:32:19

Wonderful Ab, I will explore the ways of immediate publication with websocket. Thank you very much.

fabiovip2019 · 2020-08-11 19:49:57

Hi ab, I was exploring event notifications via websockets, is that how you commented?

IUserEvent = Interface(IInvokable)
  ['{1C949DB2-5ECE-4EC6-8609-1B9FF408BDF6}']
   procedure UserCreated(const UID,Login:String);
   procedure UserDeleted(const UID:string);
 end; 


IPublisherService = interface(IInvokable)
  ['{3F3246E9-5B91-443F-A0D4-9159E532B6E8}']
  procedure PublishUser(const User:TUserDTO; const callback:IUserEvent);
  end;

This way, both publishers and subscribers can be in the application layer, right? In this example, the AppUser would publish the user event created and an event handler would call another application, an AppEmail for example, to decide what to do with this information? Or should all of this happen at the domain layer?

ab · 2020-08-11 20:20:58

There may be events in the Domain layer, or in the Application layer.
If you use a public API, then you should rather not leak the domain and use some translation of events between domain and application layer - in pure DDD.
In practice, for what I called KDD - see my blog article - I may leak the domain events if there is a single domain involved. I would create dedicated events in the application layer (as DTO only if several domains are needed to be used at the same time.

fabiovip2019 · 2020-08-12 13:20:37

Hi Ab,
I didn't understand when you say "I would create dedicated events in the application layer (as DTO only if several domains are needed to be used at the same time.", most of the time I need to use domain events is because I am communicating domains out of the delimited context. I have a situation, for example, when an order is created in the order domain and I need to communicate the stock domain to separate the merchandise. I see no other way to do it except for events. So there are several domains, right?

I didn't find your article on the blog. Can you give me the link?

ab · 2020-08-12 13:32:11

The KDD articles were in https://blog.synopse.info/?tag/KDD
In short, a way of coding with relaxed rules, but similar isolation principles than DDD.

About your design, perhaps I wouldn't create an "order" domain and a "stock" domain. It may suggest that you have two aggregates, orders and stocks, and therefore two domains - which reflect two tables in the database.
There may be a notion of "order" in two domains. What creates the bounded context is the use case it works on. The main point is having the aggregates self-containing in a bounded context.
So you may have an order with full client information in the "front end client" domain, and an order with less client information but more detailed stock information (e.g. actual stock count for each article).

So there are a lot of ways to implementing DDD.
It is about the application layer to communicate with the domains, and synchronize them.
For instance, you may have a IStockRealTime.GetCurrentStockOfArticle when preparing the order, then IStockRealTime.AssignArticleToOrder which will actually change the stock count and UnAssignArticleFromOrder to rollback an order.
It may not be events - and if you want atomicity to have an accurate stock account, I suspect it shouldn't be events, but blocking RPC method calls.

fabiovip2019 · 2020-08-12 14:07:28

I understand AB, the first time I tried to start with domains out of context I really thought about doing it in the application, because in my view with mormot it is perfect and safe. I just thought that it would not be correct to request multiple domains from a single application layer. But analyzing your answer, you may not really choose to use domino events now, but mormot rpc calls that are very safe.

mORMot Open Source

#1 2020-08-07 17:59:38

Domain Events

#2 2020-08-07 19:04:47

Re: Domain Events

#3 2020-08-10 12:49:52

Re: Domain Events

#4 2020-08-10 13:05:22

Re: Domain Events

#5 2020-08-10 14:32:19

Re: Domain Events

#6 2020-08-11 19:49:57

Re: Domain Events

#7 2020-08-11 20:20:58

Re: Domain Events

#8 2020-08-12 13:20:37

Re: Domain Events

#9 2020-08-12 13:32:11

Re: Domain Events

#10 2020-08-12 14:07:28

Re: Domain Events

Board footer