1. The Domain Event!
The Hidden Gem of DDD

2. Henrik Møller Rasmussen
Founder and CTO
The digital daycare

3. The digital daycare
6 institutions!
~1.000 children

4. Vaughn Vernon: Implementing Domain-Driven DesignEric Evans: Domain-Driven Design: Tackling …
2003
Theoretical
2013!
Practical
Domain-Driven Design

5. Do you DDD?
• Domain Model
• Repository
• Ubiquitous language
• Domain Service
• Application Service
• Bounded context
• Context map
• Domain Event
• Anti Corruption Layer
• And many more…

6. class Product {
!
protected $title;
!
protected $price;
!
public function setPrice($price) {
// ..
}
!
public function getPrice() {
// ..
}
!
public function setTitle($title) {
// ..
}
!
public function getTitle() {
// ..
}
!
}
Is this your domain model?

7. class ProductController {
!
public function addToBasketAction($product) {
if ($product->getInStock() <= 0) {
$this->redirect();
}
!
// Add to basket
}
}
Where's your business logic?

8. Let’s build a shop..

9. Models, Views and Controllers
• Domain models grow into huge classes
• Hard to reason about (mental model)
• Domain models and relations are designed for viewing purposes
• Everything is extremely coupled
• “Big ball of mud”
Package: My.Shop

10. Proper DDD

11. Product
Category
Invoice
Order
Email
Customer
Reporting
Searching
Inventory
Shipping

12. Product
Category
Invoice
Order
Email
Customer
Reporting
Searching
Inventory
Shipping

13. Catalog
Inventory
Billing
Search
Reporting
…
…
…
Bounded Contexts / Modules

14. Catalog
Domain models
Product Category
Repositories
CatalogService (Application Service)

15. Inventory
Domain models
Product
Repositories
InventoryService (Application Service)

16. There will be more than one class
representing a product

17. • Small models / modules / bounded contexts
• Easy to reason about
• Easy to test
• Loosely coupled
Benefits

18. Catalog
Inventory
Billing
Search
Reporting
…
…
…
Communication

19. Introducing
The Domain Event

20. So what is a domain event?
• It’s a message …
• .. implemented as a class
• .. published to “the world”
• It’s past tense (e.g. OrderCompletedEvent)
• It’s transactionally coupled to your domain model
• It’s asynchronous

21. class OrderCompletedEvent {
!
public $orderId;
!
public $amount;
!
public $completedAt;
!
public $customerId;
!
}
Example

22. class Order {
!
public function complete() {
$this->completedAt = new DateTime();
!
$this->eventService->publish(
new OrderCompletedEvent(…)
);
}
!
}
Publishing event

23. Catalog
Inventory
Search
Billing
MessageBus
EXAMPLE: Order Completed

24. Why not use
signal/slots for that?

25. 1. Customer places order
2. Signal / Slot trigger a foreign context to
send the order confirmation via email
3. Something breaks during persistence of the order.
What now?
Signal / Slot example

26. START TRANSACTION!
UPDATE order …
INSERT INTO event_store …
COMMIT!
!
!
If this succeeds the event is published to the message bus
Transactionally safe domain events

27. Catalog
Inventory
Search
Billing
MessageBus
EXAMPLE: InStock is updated in the inventory

28. Catalog
Inventory
Search
Billing
MessageBus
EXAMPLE: Product description updated in the catalog

29. Benefits of using domain events
• Allows you to integrate bounded contexts with minimal
coupling and dependencies.
• Add features to the system with no changes to existing code.
• Get a more responsive system since a lot of functionality
is handled asynchronous.
• Get a more robust system. Easier to build fault tolerant system.
(Fx. problems with third party services like payment gateways etc.)

30. UI
Catalog
Inventory
Billing
Search
Reporting
…
…
…

32. Is it simple to maintain?!
Does it perform?!
Yes!
No!
(Come see my talk tomorrow about CQRS)
Is it simple to build?! Yes!

33. Let’s talk Flow

34. What is a bounded context?
Package?!
Subdirectory?!
Its own Flow installation?!
Another system?
Could be any of above as long as they are independent
and only integrate through domain events (or service calls).
!
No sharing of domain models etc.

35. How do I get started?
https://github.com/agitso/event
• Uses Doctrine’s PostFlush event listener to hook into
Doctrine after persistence and handle domain events.
• The same technique is used in Famly, where we have
currently handled +500.000 domain events

36. Recap
• Split your system into smaller modules / bounded contexts
• Put your business logic into the domain models
• Integrate modules with Domain Events (use application service calls
for synchronous interactions).
• Use controllers to orchestrate the views - that is fetch data
from Application Services and assign to views and similar.
NO BUSINESS LOGIC HERE.

37. Henrik Møller Rasmussen!
hmr@famly.dk
Twitter: @heinodk
IRC: Come join us at #ddd
The digital daycare