🇺🇸 Domain Events vs. Integration Events

Arley Pádua
4 min readNov 13, 2017

Designing an application can be tricky sometimes, specially if you are designing several domains and they need to interact with each other. To prevent those complications we can take advantage of some concepts and implementations on our app.

In this post I’ll share some thoughts about Domain Events and Integration Events, some practical examples and relate them to the design of an application.

Domain Events

What is it ?
According to Martin Fowler a domain event “captures the memory of something interesting which affects the domain”.

What is it in real world ?
Lets say that John and Mark work together at the sales area of a company and they do some paper work. First of all, John creates a handwritten budget by taking a customer request and calculating some taxes. After that, Mark takes this paper and fax it to the customer (does it still exist?).

Based on this story we can note that Mark’s job is related to John’s job, but they are not necessarily tied. For example, Mark can wait for all budgets on a day and then send it to the customers.

In other words, creating a budget is part of the same domain of notifying the customer about this budget, but those actions are not part of the same process.

At the end we have a “memory” of a budget created that affects the “sales domain” by using this memory to send the budget to the customer.

What about the application’s design ?
They must be implemented within a specific domain or same logical application. It’s boundaries must be very well delimited.
If we design an application to our story, we would have the following scenario:

One application that takes a customer request, calculates the taxes, registers the budget and then publishes an event that a budget was created.
A secondary process would subscribe to the domain events, start listening to the “budget created” event and then send an email to the customer when this memory happens.

What are the benefints of it ?
I can enum some benefits:

  • Separation of concerns, making your maintenance processes easier;
  • A good modeling of your code, using the ubiquotous language concept.
  • Testability, because a process does not depend on the other.

Integration Events

What is it ?
A commited event that ocurred in the past within an bounded context which may be interesting to other domains, applications or third party services.

What is it in real world ?
Now lets say that when John finishes his job, he goes to the Marketing department of the company and delivers a copy of the budget. With this copy in hands, Julia selects some good customers to deliver a special discount coupon on next purchases.

Adding this part of the story, we may note that Julia is part of a different domain named Marketing domain.

Also, note that the same event happened on the past (budget created), but now in a different domain. This means that she doesn’t need to know how the budget was created, calculated or even sent to the customer. She only needs to get her marketing job done.

What about the application’s design ?
This scenario is not focused on the specific application design but the entire system. When we are dealing with distributed systems, we can think about having two separated applications: Sales and Marketing.

Sales app emits an “budget created” event and then Marketing app would react to that event sending the marketing campaing.

What are the benefints of it ?

  • Separation of concerns at the entire system level, as Sales system doesn’t want to know about the processes involved in other systems after an “budget created” event. And other domains that are interested can now subscribe to that event without knowing how it occurred, but when it occurred.
  • Scalability. If the Sales team work hard until the point of hundreds of budgets are created, you can open more “workers” listening to this queue of events and get the job done as the load increases.
  • Other aspect is that you can divide the projects among teams, treat them as products, and they can work, develop, change the rules without bothering the other team.

Final Thoughts

Those concepts increase the quality of you softwares, but you need to be reasonable while designing a system.

Domain Events and Integration Events can make your life easier but you must take care of when it is needed. For example, if you need to create a simple CRUD application, and nothing more is involved, certainly you don’t need to design a huge architechture to handle this. Just be reasonable and keep it simple.

This article is also available in portuguese.

--

--

Arley Pádua

Software Engineer and passionate about distributed systems