Domain Driven Design - Domain Events - Bounded Context İçinde Yaratılır

Kitabın İlk Baskısında Bu Kavram Yoktu

Açıklaması şöyle

The concept of Domain Events was however not included in Eric Evans' great book about Domain-Driven Design when it was first written but added as an appendix later,...

Domain Events Nedir?

Açıklaması şöyle. Bounded Context içindeki model'e ait Aggregate tarafından yaratılan olay nesnesidir.

In Domain-Driven Design we create a model that is valid within a Bounded Context. The context is our solution to a particular problem that we are addressing, so it can be a subsystem or a Microservice, or a monolithic application. The core principle of the Domain Model is the same - it is only valid within this context.

...

A Domain Event is an event that is spawned from this model that is a result of a decision within the domain. Within the model, our Aggregates have the role of maintaining business rules and this is where we implement decision points in our model, so the Aggregates are also responsible for creating the Domain Events.

Domain Event vs Integration Event

Açıklaması şöyle. Domain Event aynı domain içindeki diğer servislere de gönderilir. Böylece onlar da bir haberdar olup bir iş yaparlar.

Domain events indicate something important that has happened in the system from the perspective of the Business Team. Let’s take the example of Cart Entity in the Shopping cart bounded context. Events like ProductAddedToCart, ProductRemovedFromCart, CartCheckedOut are important to business teams.

Domain Events can not be updated or deleted once they happen. They can be used as a communication mechanism between different bounded contexts. So CartCheckoutEvent, when generated by Cart, can be used by Payment bounded context in e-commerce to initiate a payment from User.

Domain Event helps with building loosely coupled, scalable systems.

They are also the basis for designing Event Sourced systems.

Ancak Integration Event farklı domain'lere gönderilir. Açıklaması şöyle

... it’s important to distinguish between domain events and integration events. A domain event is something that happened in the domain that is relevant to other microservices within the same bounded context. Domain events can be part of the execution of a single business transaction. An integration event is something that happened which is (also) relevant to other bounded contexts in the system, often when the business transaction is completed successfully.

This distinction is important because events continuously adapt to new requirements as the system evolves and integration events tend to be more challenging to adapt as they form a cross-bounded context contact. Different bounded contexts are often implemented and maintained by different teams. Changes across teams require more planning and alignment since teams tend to have their own goals, priorities, and roadmap.

Domain Event İsimlendirmesi

Açıklaması şöyle

Each event is expressed in a past term verb,

 - RentExpired

 - RenctCancelled

 - RentRejected

Domain Event Hangi Bilgiyi Taşır?

Bounded Context içindeki Aggregate'ler yaratır. İçinde şu bilgiler olabilir. 

It is useful to include the originating aggregateId, from where the event was spawned and include the aggregateType and eventType to help consumers of the event to interpret it. They should be serializable just like any other type of event, and you should not include deep references to objects in the code representation of your Domain Events.

Örnek

Elimizde şöyle bir kod olsun

/**
 * The actual transportation of the cargo, as opposed to
 * the customer requirement (RouteSpecification) and the plan (Itinerary). 
 *
 */
@Embeddable
public class Delivery implements ValueObject<Delivery> {
  // code omitted
}

Açıklaması şöyle. Burada Event Storming kullanılmadan da Domain Event nesnesi/kod yaratılabileceği anlatılıyor

Delivery is a very intricate object which ties together a number of other key abstractions from the Cargo domain. It’s a result of a deep modeling insight which allows for a correct correlation between “actual transportation” (a series of actually occurred movements of a cargo through geographically determined Leg s) and the “route specification” and “itinerary” as has been specified by “customer requirement”. Almost all invariants in Cargo aggregate will involve some logic implemented in Delivery and most of the business functionality for the cargo tracking bounded context will depend on it.

Coming up with Delivery value object, especially the way it encapsulates other value objects and embodies the relationship between Cargo , Voyage, Location , and HandlingEvent aggregates — is an example of an “ah-ha moment”, an breakthrough insight which unlocks an elegant solution for the Cargo tracking problem.

The point is: the solution revolving around Delivery value object in Cargo tracking problem space was introduced without the use of Event Storming. It most certainly did result from many discussions with domain experts where specific business concepts and relations were tackled using precise Ubiquitous Language. But “distillation” of the deep model (to use Evans’ own terminology) certainly came from a developer trying out different competing models. We can imagine solutions like no Delivery value object (all logic in Cargo aggregate), Delivery as an aggregate in itself, etc.

Domain Event Ne Değildir?

- Kendi Bounded Context'imiz içinde olsa bile önem taşımayan bazı olaylar Domain Event değildir. 

- Bizim Bounded Context'imize dışarıdan gelen komutlar Domain Event değildir. 

Açıklaması şöyle

Examples of things that happen that might not be suitable to model as Domain Events:

- Something technical (a ButtonClicked, ExceptionThrown, etc) happened that we want to record or handle, but it is not described in the ubiquitous language of our domain.

- Something that happened outside of our bounded context. This could a Domain Event in another system or a different bounded context.

- Requests to your system. These we define as Commands rather than events since they can be rejected by our system.

Domain Events ve Event Sourcing

Bu iki kavram yakında ilgili. Event Sourcing yazısına bakabilirsiniz.

Domain Events ve CRUD

Açıklaması şöyle

One of the most common mistakes when starting with Domain Events and with DDD, in general, is to not go the whole way and figure out what is actually going on in the domain. It is easy to fall into the trap of naming all events SomethingCreated, SomethingUpdated and SomethingDeleted. While not a problem in itself it does not make use of the powerful thing we get by adding the context and meaning to the actual change that the Domain Event represent. You lose the intent of the event and reading the event log later will not provide that much value.

Domain Events Kullanarak Bounded Contest Arasında İletişim?

Bu mümkün. Açıklaması şöyle

Domain Events enable communication between bounded contexts by avoiding direct calls. So a bounded context, B1, raises an event and one or more bounded contexts, B2...Bn subscribers to this event, should handle the event to consume it.