Show how the pattern helps to work with different persistence implementations (Doctrine, MongoDB driver, SQL driver) while keeping the code completely decoupled and contained in the Infrastructure layer.

Explain ES and share the trait that feeds Aggregate Roots with the capability to apply ES easily.

Query

Command

Application Services and Specialized Queries (Payment Orders)

Take the first example from the beginning of the book.

Also take the ContractStrategy example.

Explain the problems of breaking the law as we make more classes depend on inner classes.
Show how to avoid breaking the law when testing by using Domain Events to test (Booking Request)

Creating fixture for unit tests gets more complex as long as the code grow. Different shapes of a given class need to be instantiated to test all the different paths in a test.

Show how the FixtureBuilder helps to create, in a readable way, different fixtures of the same class (PaymentOrders)

Although not a pattern, an example can be provided to show the benefits of this architecture when working with different adapters (Rest, Soap, Mongo, AMQP, sql) for a given port (Http, Persistence, Messaging).

Take it from two of my answers in stackoverflow

Explain how useful is to use this pattern as you forget about how the collection (array, ArrayCollection, Doctrine array,...) making easy for all your clients to use the collection. We have seen the problems of working with arrays when doctrine returns a custom collection which extends IteratorInterface. In this way, even if php in the future adds ArrayCollection or something similar if it implements the common interface we are all safe.