Friday, 14th June in London

9 experts spoke.
Overview

We cannot generalize from one example. Until recently, DDD has been applied almost exclusively within a single paradigm of object-oriented programming with objects mapped into some form of server storage. Now that has changed.

DDD principles are being applied in functional programming, graph databases, and in document-based and event-oriented systems. This is beginning to give us perspective. Which DDD patterns apply to graphs or document systems? Do we need new building blocks or altered versions of old ones? We are learning about this now. In the process, we gain deeper insight into the essence of DDD, and how to focus where.

Several of the talks at DDD Exchange describe the explorations of some of our DDD experts in these directions. We are in the middle of this now, and, it is impossible to know where this will lead. Perhaps we will end up with refined approaches to apply DDD in diverse paradigms. Perhaps the new insight will come full circle, resulting in fresh approaches to DDD within object-oriented software. For now, we try new things and learn.

Excited? Share it!

Programme

Systems and Domains. Triplet Sons of Different Mothers

The domain model of an application describes the organization and partitioning of the business logic and rules. The business can look at that model and recognize itself. This is a good thing; but it's only part of the problem. An application is a system that connects the business domain model, the technical domain, and the specific use cases of a particular application. These three aspects of an application are often at odds with each other because they have opposing needs and affordances. It is the job of the System Architecture to balance those forces allowing these competing application aspects to work in harmony. Getting this right is critical to the lifecycle of the application and is an essential element in creating well-crafted applications.



Uncle Bob (Robert C. Martin)

Robert Martin (@unclebobmartin) is Master Craftsman at 8th Light, Skills Matter instructor and author of a range of books (as well as hundreds of articles), including: Clean Code: A Handbook of Agile Software Craftsmanship as well as his most recent, Clean Architecture: A Craftsman's Guide to Software Structure and Design.


Rethinking Enterprise Software



Alberto Brandolini

Alberto Brandolini can model every business domain, given enough space, a paper roll and an unlimited source of colored sticky notes (with a preference for orange ones). He calls this stuff EventStorming.


Email, Ubiquitous Language, Visualization & Clojure: Eric's Sandbox Project



Eric Evans

Eric Evans, author of Domain-driven Design: Tackling Complexity in the Heart of Software is a thought leader in software design, domain driven design and domain modeling and particularly focuses on strategic design.


Welcome: Eric Evans



Eric Evans

Eric Evans, author of Domain-driven Design: Tackling Complexity in the Heart of Software is a thought leader in software design, domain driven design and domain modeling and particularly focuses on strategic design.


PARK BENCH PANEL DISCUSSION



Zi Makki

Just another .net developer that loves doing 'stuff' for the community.Zi is on the DDD committee and is helping out with WebDD wherever possible.


PARK BENCH PANEL DISCUSSION



Zi Makki

Just another .net developer that loves doing 'stuff' for the community.Zi is on the DDD committee and is helping out with WebDD wherever possible.


DDD with Ruby on Rails and MongoDB

Ruby has a rich OSS ecosystem, a vibrant agile development community, a strong commitment to design, and many talented modelers and designers. Yet using DDD to do strategic design and domain modeling is virtually unknown in the Ruby community. This presentation is an attempt to bridge the gap via an exploration of what DDD might look like through Ruby/NoSQL-coloured glasses. The basis for this will be a port of the DDD sample app to Ruby on Rails using MongoDB for persistence.

We'll cover interesting questions such as: How does the choice of Ruby affect the implementation of the DDD building block patterns? How well does an opinionated MVC framework like Rails support doing DDD? How well does an opinionated MVC framework like Rails support doing DDD? What are implications of choosing a document store like MongoDB for aggregate design and eventual consistency?

In the process we'll highlight significant lessons learned from porting the DDD sample app to Ruby/MongoDB, some significant concerns and aim to show potential ways forward.



Paul Rayner

Paul Rayner is a programmer, coach, mentor, trainer, and popular international conference speaker.


Miching Mallecho: Mischief, Motivation and Graph Models

Every model is motivated by a need; every model is constrained by its mode of representation. For decades our industry has favoured the directed graph as a means of expressing its modelling flights of fancy. We're surrounded by graphs: object graphs, entity-relationship diagrams--even our circle-and-lines whiteboard sketches. Why then do we surrender our graph competence at the last moment, when it comes to making our model durable? What mischief interrupts the path from thought to deed? In this session I'll discuss why and when we might consider applying a graph all the way down the stack, from whiteboard to persistent storage. I'll show how we encode our model's needs in the graph, and how a graph database helps fulfill the needs that motivate the model.



Ian Robinson

Ian Robinson is Director of Customer Success for Neo Technology, the company behind Neo4j, the popular open source graph database.


How DDD became an essential ingredient for competitive software in the energy sector

Exploring for oil is an expensive business, getting it out of the ground even more so. Discovering, describing and simulating oil reservoirs is a competitive software-intensive activity. The dominant players must provide unique advantages within the constraints of off-the-shelf software systems.

Domain models and their APIs, which provide firm foundations for innovative customisations, have emerged as a major product differentiaton in a billion dollar shrink-wrap software market. In this session I’ll illustrate the benefits and challenges – both technical and cultural – encountered by one company in applying DDD to “shared earth models” which were hitherto implicitly encoded in legacy systems. I’ll also discuss the all-important business imperatives that have motivated the adoption of domain modelling in the oil and gas software industry.



Robert Smallshire

Robert Smallshire is Founding Director of Sixty North, a software product and consulting business based in Norway. He has designed and implemented architectures for complex scientific and enterprise software in Python, C++, and C#, and is a regular speaker and coach.


Keynote: DDD and Actor Model



Vaughn Vernon

Vaughn is a veteran software craftsman, with more than 35 years of experience in a broad range of business domains, Vaughn is a leading expert in DDD and champion of simplicity and Reactive systems.


Document based messaging and analysis



Greg Young

Greg Young coined the term "CQRS" (Command Query Responsibility Segregation) and it was instantly picked up by the community who have elaborated upon it ever since.


SkillsCasts
Photos
Other Years


Thank you to our sponsors and partners


Platinum