Two Weeks Left to Take Advantage of NYC Early-Bird Discounts

• May 3, New York, DDD Overview
  $690  $590 if booked by 4/9
• May 4, New York, DDD Immersion
  $2790  $2490 if booked by 4/9

Course descriptions, registration and more dates here  »
Or call us at: (+1) 914 482 1273

Does New York seem a little daunting?

New York can seem a little overwhelming, but it can be fun too. Our classes are small and personal. Give us a call, and we can provide advice on hotels, dining, navigating the subway, and whatever else you might need.

DDD eXchange London, June 11

Second annual DDD eXchange in London

This year's program will feature an exciting set of talks emphasizing architectural innovations and DDD (especially CQRS and Cloud Computing), integrating DDD and Agile/Lean, and, as always, real-word experiences applying DDD. Eric Evans is working with other DDD leaders to finalize the program.

With seven expert talks and two Parkbench sessions, the program is structured to encourage discussion and interactivity. To further encourage this, the number of attendees is limited to 125 delegates, so everyone who attends can talk to the experts, learn and generally have lots of fun. Learn more and sign up  »

Immerse yourself!

Enroll in the DDD Immersion course June 7-10 and get free admission to DDD eXchange.

Blogging the DDD Immersion

The DDD Immersion is an unusual class. Rather than endless slide-shows, we take people through simulations and discussion with our expert instructors that help the attendees absorb the principles of DDD and deepen the way they think about design.

Paul Rayner, a very experienced developer and agile coach, attended the DDD Immersion in New York in February and wrote an awsome seven-part series describing his experience. Check it out  »

Much of day 3 is structured within the framework of a play. A roleplay. With scripts and characters to act out. A mystery play. We really got into the acting and the characters and had a lot of fun with it...

We struggled to understand how to get the characters out of the difficult design and organizational situations in which they found themselves. But this is where the discussion with the instructors after each Act really drove the point home.

Eric and Kristian guided us through each of the major strategic design patterns, showed how they applied to each aspect of the system and organization, and enabled us to see the way forward in each case. By the time we were done, I felt like I finally had a coherent structure and language for describing and understanding the variety of team and design situations/arrangements, and a proven approach for making improvements where they are likely to do the most good.

...I was familiar with these from reading the DDD book a few times, but it wasn’t until I took the course this week and went through the roleplay with the other students that it finally “clicked” for me. I realize I need to really grok these patterns, and learn to apply them in every client engagement.

Paul Rayner, March 2010  »

Modeling Domain Events, Another DDD Building Block

by Eric Evans

A domain event is a model representation of something that happened that is interesting to a domain expert. This is distict from the system events that coordinate activity within our software.

Over the last few years it has become clear that it is very useful to add a new pattern to the DDD "Building Blocks" (Entities, Value Objects, Services, etc.) -- Domain Events. This pattern has been around for a long time. Martin Fowler wrote a good description. In the last few years, I've been working on integrating it into the DDD pattern language.

The problem

An entity is responsible for tracking its own state and the rules regulating its lifecycle. Yet the actual origin and cause of a state change is typically not explicit. This makes it difficult to explain how an entity got into its current state, which is often a business or legal requirement and may also be important to development and support, in order that they can verify correctness of the program and trace errors. Audit trails allow tracing, but are not suited to being used within the logic of the program itself. Change histories of entities allow access to previous states, but ignore the meaning of those changes. In practice, this means that any manipulation of the information is procedural, and usually pushed out of the domain layer.

A distinct, though related set of issues arises in distributed systems. The state of a distributed system cannot be kept completely consistent at all times. We keep the aggregates internally consistent at all times, while making other changes asynchronously. As changes propagate across nodes of a network, it can be difficult to resolve multiple updates arriving out of order or from distinct sources.

Enter domain events.

Model an event in the domain that may lead to state change as a domain object. Also model events that the domain experts want to track or be notified of. These are distinct from system events that reflect activity within the software itself, although often a system event is associated with a domain event, either as part of a response to the domain event or as a way of carrying information about the domain event into the system.

A domain event is a full-fledged part of the domain model, a representation of something that happened in the domain.

In a distributed system, the state of an entity can be inferred from the domain events currently known to a particular node, allowing a coherent model in the absence of full information about the system as a whole.

Domain events are ordinarily immutable, as they are a record of something in the past. In addition to a description of the event, a domain event typically contains a timestamp for the time the event occurred and the identity of entities involved in the event. Also, a domain event often has a separate timestamp indicating when the event was entered into the system and the identity of the person who entered it. When useful, an identity for the domain event can be based on some set of these properties. So, for example, if two instances of the same event arrive at a node they can be recognized as the same.

Key to Innovative Architecures

Even in a conventional architecture, Domain Events makes state-change explicit. In many of the currently emerging architectures this pattern takes center stage.

In Command Query Responsibility Segregation (CQRS), an architecture that extends DDD into the relm of high transaction volume and one of the hottest topics in DDD right now, every state change must be represented explicitly as an event.

In Cloud Computing, Domain Events allow us to maintain clear models in the face of eventual consistency, so that an application might be deployed as a miriad of separate separately deployed elements. Guided by the Aggregate boundaries, these elements can follow clear rules defined in the domain model, while unreconciled changes are represented as Domain Events, propagating through the system, being interpreted within other aggregates.

The combination of Domain Events and Aggregates sets us up to make domain modeling even more relevant in the next generation of enterprise systems.

If you are interested in CQRS and Cloud, they will be major topics discussed at DDD Exchange in June.