KanDDDinsky
The art of business software
18.-19. October 2018
H4 conference hotel, Berlin

Schedule

Thursday, 18.10.2018

08:30 - 09:30
Registration
09:30 - 10:30
Michael Feathers
The Design of Names and Spaces
Room One, 09:30 - 10:30
×

Michael Feathers

The Design of Names and Spaces
Room One, 09:30 - 10:30
Keynote
10:30 - 11:00
Coffee
11:00 - 12:00
Kenny Baas-Schwegler
(Talk) Crunching 'real-life stories' with DDD Event Storming and combining it with BDD
Room One, 11:00 - 12:00
×

Kenny Baas-Schwegler

(Talk) Crunching 'real-life stories' with DDD Event Storming and combining it with BDD
Room One, 11:00 - 12:00
To really understand what our users will need, we want to have a first-hand experience from 'real-life stories' before we can model and create our software. While both the DDD and BDD techniques emphasis on ‘real-life stories’ by doing collaborative deliberate learning, they both focus on different goals. DDD focuses more on creating bounded contexts in which a single model is created, BDD focuses more on different scenarios and can create executable specifications as an outcome. By doing Event Storming and using techniques from BDD, such as Example Mapping and Feature Mapping, we can create more insights. We can simultaneously create a model and executable specifications for our user needs. This way, we can write software and tests which matches the shared understanding of the user, creating a ubiquitous language. Value will be shipped at a faster pace.

In this session, I will explain how to do Process Event Storming. We will use Example Mapping to get more insights into our process. The outcome can drive our Software Modelling Event Storming and create Executable Specifications.
Uberto Barbini
Functional CQRS in Kotlin
Room Two, 11:00 - 12:00
×

Uberto Barbini

Functional CQRS in Kotlin
Room Two, 11:00 - 12:00
This presentation will be using live coding to show how to implement and implement a CQRS architecture using functional abstractions, pure functions and immutable data using Kotlin as language.
CQRS concepts go very well together with functional programming principles of immutability and high level functions.
Participants don't have to know Kotlin or functional programming but the knowledge can be beneficial.
The session will try to capture the main architecture critical decision in implementing a cqrs application. We also believe that using a functional approach simplify the code and avoid some typical pitfalls in event store implementations. Of course it can bring to other problems so we will discuss those as well.
Pim Elshoff, Joop Lammerts
(Di|Con)vergent Mob Refactoring
Room Three, 11:00 - 13:00
×

Pim Elshoff, Joop Lammerts

(Di|Con)vergent Mob Refactoring
Room Three, 11:00 - 13:00
Programmers come in all kinds and sizes. But we’ve found that there is one major distinction that keeps us from working together: attitude. Optimistic programmers tend to come up with solutions quickly, while not always respecting the problem. Pessimistic programmers tend to come up with questions quickly, while not always respecting simpler solutions.

Working together can be difficult. But by explicitly diverging and converging we can find respect for each other and what we have to bring to the table. By working together we find better solutions than we could working alone.

We will group up in teams of four or five, in so called mobs, and work on a case study in pomodoro’s. We will first diverge, to give the optimists their moment in the spotlight, where they can create tempo and get some things done. Then we will converge and give the pessimists the power, where they can refine and get things done well. If you’re not sure what your attitude is, then we will help you discover it.

We will be helping MeetInc. Their current implementation of what a meetup is, is sorely lacking. And the business has come with new rules. We will use this opportunity to make the code reflect the domain of meetups better.

Your exact mission, should you choose to accept it, is available on GitHub at https://github.com/procurios/diconvergent. And fear not, you are not alone. Your team is there with you, as are the business experts, who can answers all of your questions.

Topics include
* Refactoring anemic models to useful domain concepts
* Divergence and convergence
* Timeboxing
12:00 - 13:00
Julie Lerman
Getting to DDD: Pragmatic or Principled?
Room One, 12:00 - 13:00
×

Julie Lerman

Getting to DDD: Pragmatic or Principled?
Room One, 12:00 - 13:00
Domain-Driven Design is a vast topic. There are so many wonderful concepts, philosophies, patterns, practices and techniques to learn and benefit from. Some of the best minds in the industry have been tuning these practices for years to ensure developers are able to implement proven, successful approaches to software design. Domain modeling in particular is very specific with guidance on designing and coordinating the dance between the myriad moving parts in our system. Yet learning the principals of DDD can be daunting for developers who are new to DDD. To encourage and enable more developers to get on the path of DDD, is it reasonable to allow a more pragmatic approach over a principled approach of adhering strictly to DDD guidelines? Should developers be encouraged to start with low hanging fruit which they can quickly benefit from in their software projects while they continue to learn, to gain a deeper understanding of Domain-Driven Design in order to evolve and adapt their practices as they move closer and closer to the beauty we all know that can be achieved with DDD.
Camal Cakar
Lessons learned from a cab drive about Serverless
Room Two, 12:00 - 13:00
×

Camal Cakar

Lessons learned from a cab drive about Serverless
Room Two, 12:00 - 13:00
The current Developer Survey on Stackoverflow shows that "Serverless" ranked 2nd place among the most popular platforms in 2018.

Time to get a closer look at the topic before you lose the loop.

After some projects in the Serverless World, Camal will give us an introduction to the topic that he himself would have "liked to have" a year ago.

Any similarities with other technologies or applied software mythologies are intended.
13:00 - 14:30
Lunch
Zsófia Herendi
Buddy #DDDMeetupOrganizers meetup
Room Three, 13:00 - 14:30
×

Zsófia Herendi

Buddy #DDDMeetupOrganizers meetup
Room Three, 13:00 - 14:30
To all #DDDesign meetup organizers and those who want to become one. We'll meet during the lunchbreak with Zsófia Herendi in a get-together to share experiences and inspirations.
14:30 - 15:30
Kevlin Henney
What Do You Mean?
Room One, 14:30 - 15:30
×

Kevlin Henney

What Do You Mean?
Room One, 14:30 - 15:30
"It's just semantics." How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment?

Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — it's discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning.

But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it's just semantics, that doesn't mean we're necessarily good at it. It takes effort and insight. Let's talk about what we mean.
Trond Hjorteland
From Capabilities to Services: Modelling for business-IT alignment
Room Two, 14:30 - 15:30
×

Trond Hjorteland

From Capabilities to Services: Modelling for business-IT alignment
Room Two, 14:30 - 15:30
Our industry seems to go through cycles of re-discovery of lost knowledge with every new generation of developers, which probably is not so odd considering the exponential growth of practitioners. Allegedly half of the programmers today are juniors, which means many of them have yet to encounter the challenges faced decades ago. For example, many run the risk of falling into the trap of modelling services around domain entities, risking ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare. Lucky for us, we have shoulders to stand on to get us out of the quagmire, or even better, prevent us from getting on that slippery slope in the first place.

Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. There are many great techniques to consider, like context mapping, user story mapping, event storming, and value chain analysis, but in this talk I will focus on the lost art of business capability modelling. My thesis is that a technique that was just as relevant in the pre-computing era might be just as useful and relevant when we split our monoliths into a mesh of autonomous (micro)services.
Bruno Boucard, Thomas Pierrain
Distill the Core Domain from Your Legacy App
Room Three, 14:30 - 16:40
×

Bruno Boucard, Thomas Pierrain

Distill the Core Domain from Your Legacy App
Room Three, 14:30 - 16:40
Let's take a very common legacy application: procedural code everywhere, anemic domain logic fully entangled with technical concerns and code. Nothing but classical stuff, right? Our mission for this truly interactive live-coding session will be to identify and extract the core domain logic out of this tar pit in order to add a new feature that has been desperately asked by our business since months.
Last but not least, we will clean the situation for the years to come by properly splitting the domain code from the technical one using the Hexagonal Architecture pattern.
Ready to help us in that journey?
15:40 - 16:40
Zsófia Herendi
Encouraging DDD Curiosity as a Product Owner
Room One, 15:40 - 16:40
×

Zsófia Herendi

Encouraging DDD Curiosity as a Product Owner
Room One, 15:40 - 16:40
Have you thought about what happens if you don't know your domain? And what happens if you don't even want to know more? Lack of curiosity can cause you a lot of trouble. Zsófia will tell you about how a Product Owner can contribute in DDD to broaden your knowledge in the domain and how Product Owners can make you more curious. You will get tips and hints what you should definitely talk about with your Product Owner.
Henning Schwentner, Stefan Hofer
How Domain Storytelling reveils the secrets of your domain
Room Two, 15:40 - 16:40
×

Henning Schwentner, Stefan Hofer

How Domain Storytelling reveils the secrets of your domain
Room Two, 15:40 - 16:40
Domain Storytelling means that we bring together domain experts and developers. We let them tell us stories about their domain. While listening, we record the stories using a pictographic language. The experts can see immediately if we understand their story. After very few stories, we are able to talk about the people, tasks, tools, work items, and events in that domain.
Henning and Stefan will demonstrate Domain Storytelling by re-enacting how they modeled ship maneuver planning in the port of Hamburg. You will see that Domain Stories show how people work together within and across contexts – and how unsuitable boundaries prevent people from working together. After all, bounded contexts should separate models, not people.
16:40 - 17:30
Coffee
17:30 - 18:30
Mathias Verraes
Design Heuristics
Room One, 17:30 - 18:30
×

Mathias Verraes

Design Heuristics
Room One, 17:30 - 18:30
Software design principles aspire to be universal. And yet, when you create software, you sometimes intentionally violate principles. You might not be able to explain why this "wrong" design somehow "feels" better. You're applying your own, unspoken design heuristics. Bringing them out in the open, improves design discussions, and helps us build a larger toolkit for making better tradeoffs. In this session, we'll explore the benefits of distilling your design heuristics using practical examples.
Vladik Khononov
Bounded Contexts, Microservices, and Everything In Between
Room Two, 17:30 - 18:30
×

Vladik Khononov

Bounded Contexts, Microservices, and Everything In Between
Room Two, 17:30 - 18:30
“95% of the words are spent extolling the benefits of ‘modularity’ and that little, if anything, is said about how to achieve it” - Glenford J. Myers, 1978. This quote is 40 years old. Today, 4 decades later, nothing has changed except terminology. Time to fix this.

I want to talk about the various strategies of decomposing systems into modular components. We will learn what exactly Bounded Contexts and Microservices are. See how and why they differ. Analyze what happens between services - how data flows, and how this flow can be optimized. Ultimately, we will explore different decomposition strategies and heuristics for designing modular systems. Systems that aren’t driven by ever-changing fads, but by your business needs.
Dennis Doomen
Event Sourcing Done Right - Experiences from the Trenches
Room Three, 17:30 - 18:30
×

Dennis Doomen

Event Sourcing Done Right - Experiences from the Trenches
Room Three, 17:30 - 18:30
Over the years I've spoken many times about what Event Sourcing is and shared many of the good, the bad and the ugly parts of it in blog posts and various talks. However, I've never talked about how to actually build a system based on this architecture style. I keep getting the same questions over and over again. Like when to apply Event Sourcing and at what architectural level. How to deal with transactional boundaries within and outside the domain. How to build projections that are autonomous, reliable and self-supporting. How to deal with upgrades and blue-green deployments. But also on how to handle bugs, design mistakes and crashing projections. Having made a lot of these mistakes myself over these years, it's time to share my current thoughts and opinions about this. Since the .NET space has a pretty rich set of open-source projections to support this, the examples and code will be .NET. But the concepts are universal, so don't let that scare you off.
18:30 - open
Evening Reception

Friday, 19.10.2018

09:30 - 10:30
J. B. Rainsberger
Some Underrated Elements of Success for the Modern Programmer
Room One, 09:30 - 10:30
×

J. B. Rainsberger

Some Underrated Elements of Success for the Modern Programmer
Room One, 09:30 - 10:30
Every few years, some prominent programmer writes a book containing all their best ideas: the ones that they believe helped them become the successful people that they believe that they have become. Allow me to continue this tradition by sharing a handful of ideas, techniques, or books that, it seems, have helped me get where I am today. This could be useful to you if, for some reason, you think you'd like to be where I am. (And perhaps even if you have the good sense not to want that.)

Since a talk like this could last several hours and a book like this could run for hundreds of pages (have you seen my first book?), I will try to talk only about things that have had the greatest impact on me and I will do my best to distill them down to the essential parts. I welcome questions, objections, and suggestions for alternatives! (I don't have all the answers, even though one might expect someone on stage to fool themselves into believing that they do.)

Also, let's remember that programmers live most of their life outside their code. I will include not only some ideas about programming and software design, but also a few key ideas that have helped me reduce or avoid stress at work. We probably won't see actual code, but we'll draw some lines and boxes, and as any modern software architect will tell you, the lines and boxes are the only important parts, anyway.
Heather Downing
Speak To Me: Voice App Conversation Practices
Room Two, 09:30 - 10:30
×

Heather Downing

Speak To Me: Voice App Conversation Practices
Room Two, 09:30 - 10:30
What does it mean to develop a good interaction - without any visual aids? Natural Language Processing (NLP) has opened the door to communicating vocally, and made more easy to develop with popular platform APIs and in-home devices like Google Home and Amazon Echo. How do you start thinking about building for one of these platforms, or all of them? We will go over what has to be kept in mind for the development life cycle and empower you to make the architectural decisions that make sense with this emerging software skillset. This is a high level architectural and voice design discussion to avoid pitfalls and enhance user delight with your chatbot or voice skill.
Silver Oliver, Anya Somerville
Agile data modelling for parliament(s?): using Domain Driven Design
Room Three, 09:30 - 10:30
×

Silver Oliver, Anya Somerville

Agile data modelling for parliament(s?): using Domain Driven Design
Room Three, 09:30 - 10:30
The offices that make up UK Parliament have largely evolved independently, and over many years. Organisations with co-evolving parts are complex, making it difficult to design common data representations. At the UK Parliament, this has resulted in disjointedness in the data, internal tools, the public website and the open data we publish. This case study outlines our use of tools to address this problem. The approach acknowledges and addresses areas of organisational complexity and follows an agile methodology. We have had success pairing the flexibility and expressiveness of the RDF data model with domain driven design. The outcome mitigates many of the previous modelling design issues associated with parliamentary projects.
10:30 - 11:00
Coffee
11:00 - 12:00
Lorraine Steyn
Systems Thinking
Room One, 11:00 - 12:00
×

Lorraine Steyn

Systems Thinking
Room One, 11:00 - 12:00
Systems thinking is the macro behaviour that we must understand in analyzing our world. A system always produces what it is designed to do, even if that isn't at all what we meant it to do!

Systems are self-maintaining, and contain balancing and/or reinforcing feedback loops.

We'll look at how these work, and what happens when they fail. We'll apply systems thinking to team behaviour to show how systems are all around us.
Roman Sachse
Do-It-Yourself: Event-Sourcing
Room Two, 11:00 - 12:00
×

Roman Sachse

Do-It-Yourself: Event-Sourcing
Room Two, 11:00 - 12:00
So you heard so much stuff about Event-Sourcing. Now you want to know what all the hype is about but you don’t know where to start. Everything sounds quite complicated and there are many new concepts to learn. Do you need to use one of the available frameworks? Do you really need solutions for problems that you might never encounter? Wouldn’t it be great if you could experience those problems first-hand and to be able to tailor solutions to your application’s specific needs? In this session, I want to take you on a journey that will eventually enable you to build your own Event-Sourced system. Together we will define the requirements and I am going to give you ideas and and approaches to fulfill those requirements. The language in use will be F# but the concepts should transfer to other languages easily.
Thomas Coopman
Domain Driven Refactoring
Room Three, 11:00 - 13:00
×

Thomas Coopman

Domain Driven Refactoring
Room Three, 11:00 - 13:00
Refactoring, Improving the Design of Existing Code from Martin Fowler has a huge list of possible refactoring methods, but what methods make sense in DDD? What if we change the title to "Improving the Domain Driven Design of Existing code"? In this hands-on you try to improve the design of some program by applying refactoring methods that make sense from a DDD perspective.

This is a hands-on session where you will be coding. Don’t forget to bring your laptop or be prepared to pair with someone else!
12:10 - 13:10
Dennis Traub
How to Model Your Domain in a Serverless World
Room One, 12:10 - 13:10
×

Dennis Traub

How to Model Your Domain in a Serverless World
Room One, 12:10 - 13:10
Back in the day, when Eric Evans came up with Domain-Driven Design and its modeling patterns, there were no Microservices and certainly no Serverless Compute.

Modeling a rich domain has always been hard, and it has become even harder with a modern architecture's share-nothing approach, while multiple services/functions still need to operate on a common domain model.

In this session, Dennis proposes some patterns to model the richness of a business domain without turning your services/functions into a Distributed Big Ball of Mud.
Mariusz Gil
Modeling complex processes and time with Saga/Process Manager patterns
Room Two, 12:10 - 13:10
×

Mariusz Gil

Modeling complex processes and time with Saga/Process Manager patterns
Room Two, 12:10 - 13:10
Time modeling is always difficult, as well as implementing business flows inside complex domains. Long lived transactions which span multiple bounded contexts, possible success and failure scenarios are even more difficult to model, test and implement. Fortunately, we have an answer to this problem! Multiple messages, events, aggregates and bounded contexts? Saga and Process Manager patterns may be very helpful… During this talk you will learn how to model long running business processes which affect many regions inside domains, what are the best possible use-cases and how to use them in applications based on CQRS/EventSourcing concepts.
13:10 - 14:30
Lunch
14:30 - 15:30
Uwe Friedrichsen
Timeless design in a cloud native world
Room One, 14:30 - 15:30
×

Uwe Friedrichsen

Timeless design in a cloud native world
Room One, 14:30 - 15:30
We struggle with good functional design for as long as we build software at scale - which is for roughly 60 years meanwhile, and we haven't solved the problem by far.

But while in the past bad design only meant a hard to change and maintain codebase, the consequences are much more drastic these days. In times of microservices, cloud native, APIs and more, bad design also leads to brittle, poorly scalable and available and sometimes even insecure systems at runtime. Additionally, it often leads to poorly accepted APIs, which in the worst case threatens our business.

So, good functional design is needed more desperately than ever. But easier said than done. What is good design and how can we create it?

In this session, first we will examine, why and how functional design affects the aforementioned properties of a system. Then, we will collect several timeless design foundations, traveling through several decades of computer science. After that, we will apply the concepts learned to our challenges today. Finally, we will derive a little design guide containing dos and don'ts for successful functional designs.

After this session, you will have gained a better understanding how to design modern systems that are successful and sustainable in development and operations.
Nicole Rauch
Beyond Consumer-Driven Contract Testing
Room Two, 14:30 - 15:30
×

Nicole Rauch

Beyond Consumer-Driven Contract Testing
Room Two, 14:30 - 15:30
Loosely coupled systems (a.k.a. distributed systems / microservices) are gaining more and more traction. This implies that there is a growing demand to automatically and reliably ensure that these modular systems play nicely together. The current industry-strength approach for testing the APIs between components is Consumer-Driven Contract Testing (CDCT). Despite its unquestionable improvements over naive integration tests, it still has a number of weaknesses.
This talk points out these weaknesses and shows how we can go beyond CDCT by leveraging modelling in combination with an approach borrowed from formal methods.
Kenny Baas-Schwegler
(Hands-On) Crunching 'real-life stories' with DDD Event Storming and combining it with BDD
Room Three, 14:30 - 16:30
×

Kenny Baas-Schwegler

(Hands-On) Crunching 'real-life stories' with DDD Event Storming and combining it with BDD
Room Three, 14:30 - 16:30
To really understand what our users will need, we want to have a first-hand experience from 'real-life stories' before we can model and create our software. While both the DDD and BDD techniques emphasis on ‘real-life stories’ by doing collaborative deliberate learning, they both focus on different goals. DDD focuses more on creating bounded contexts in which a single model is created, BDD focuses more on different scenarios and can create executable specifications as an outcome. By doing Event Storming and using techniques from BDD, such as Example Mapping and Feature Mapping, we can create more insights. We can simultaneously create a model and executable specifications for our user needs. This way, we can write software and tests which matches the shared understanding of the user, creating a ubiquitous language. Value will be shipped at a faster pace.

In this hands-on session, we start with a Process Event Storming. We will use Example Mapping, and Feature Mapping to get more insights into our process. Eventually, I will show you how the outcome can drive our Software Modelling Event Storming and create Executable Specifications. This way we can create a ubiquitous domain language that we can use in our application and test code. You don't need a laptop for this session as the focus is on the discovery phase.
15:40 - 16:40
Nick Tune
Strategic Autonomous Design: Patterns and Heuristics
Room One, 15:40 - 16:40
×

Nick Tune

Strategic Autonomous Design: Patterns and Heuristics
Room One, 15:40 - 16:40
Model the wrong boundaries in your systems and disaster is just around the corner waiting to tease your sanity. An excess of dependencies between modules will result in changes rippling across a fragile codebase, or small runtime errors in one service bringing the entire system crashing down. Modelling the wrong boundaries will test the patience of your teams, too. Every major piece of work will require expensive coordination with many other teams who all have different priorities and political agendas.

In this talk, you’ll learn practical techniques for identifying effective modularity in your software systems and enabling autonomous teams in your organisation, and you’ll see sociotechnical patterns based on real world examples from a variety of domains including government, digital media, and IoT systems. Along the way, you’ll learn about the theoretical concepts underpinning the techniques, touching on DDD, Systems Thinking, Promise Theory, Theory of Constraints, and more.
Yves Lorphelin
Tamed Eventual Consistency
Room Two, 15:40 - 16:40
×

Yves Lorphelin

Tamed Eventual Consistency
Room Two, 15:40 - 16:40
"In Event Sourced systems, Latency is feared by the Developpers, and Eventual Consistency is uncacceptable for Business"

Most of us have been taught that users want to see the result of actions in our systems immediately.
And that therefore a typical transnational system is a must.

And so, we stopped thinking about time.
And so, we stopped asking:
* How long are you willing to wait
* Does it make sense to show an immediate response

Event sourcing, and the associated use of CQRS (Command Query Responsibility Segregation) has put time back as a first class citizen in our systems.
And made the need of discussions about latency explicit.

Latency and Eventual consistency is not a fatality.
It is a matter of modelling.
Modelling event streams.

This talk will explore an eventsourced subsystem, build for a government HR agency.
The steps used to tame eventual consistency inside it.
As well as those taken for integrating it into the whole Legacy system.
16:40 - 17:00
Coffee
17:00 - 18:00
All of you
Closing session
Room One, 17:00 - 18:00
×

All of you

Closing session
Room One, 17:00 - 18:00
Be prepared to be surprised.

Workshops: 17. October

The workshops will be held from 09:00 until 17:00 on the first floor of the H2 Hotel.
Find the location

J. B. Rainsberger

Surviving Legacy Code

Friends don't let friends remain afraid to change their code.

In this full-day workshop, we'll discuss and practise techniques for rescuing legacy code (the easy part), managing the work involved (the harder part), and navigating the people involved (the hardest part, by far). We'll spend most of the day refactoring some lovably annoying code, but we'll reserve part of the day to discuss how Theory of Constraints, Getting Things Done, and the Satir Interaction Model can help you with the legacy code work that goes beyond the code.

Bring a computer with a working programming environment, including version control. We'll provide the code for you to work on. Also bring your biggest doubts and your toughest questions. If we can't solve your problems, we'll help you figure out how to figure out how to solve them.
Book your ticket

Mathias Verraes

DDD Modelling vs Implementation

The design patterns from Domain-Driven Design are gradually entering the collective consciousness of software developers. But most of the information out there focuses on mechanistic implementation details of the patterns: how to make an Entity in [insert favourite programming language], how to use the Repository pattern with [insert new hot ORM], how to make immutable Value Objects in [insert legacy framework]...

Applied individually, these patterns are useful, but are not giving you the full potential of Domain-Driven Design.

This one day training has a different approach. We address technical concerns in implementing the DDD patterns, but the focus is on the underlying principles and heuristics for building great domain-centric object-oriented code.

* Why you’re underusing Value Objects
* Seeing objects as containers of lifecycles and consistency
* Discovering deeper domain concepts such as business rules, and lifting them into first class domain objects
* The relevance of processes, behaviour, temporal modelling... for finding better Aggregate boundaries
* How mutable software designs have distorted our perception of mutability in the domain
* Better heuristics for understanding a complex domain, and using them to drive a more focused design
* Reducing our dependance on service classes
* Designing an implementation model that not only encapsulates the domain, but communicates that design to future programmers and reduces their surface area for bugs
* ...

This workshop, aimed at programmers, is designed to give you immediate benefits when modelling and implementing the most important parts of your codebase.
Book your ticket

Kevlin Henney

Patterns for the People

Apparently, everyone knows about patterns. Except for the ones that don't. Which is basically all the people who've never come across patterns... plus most of the people who have.

Singleton is often treated as a must-know pattern. Patterns are sometimes considered to be the basis of blueprint-driven architecture. Patterns are sometimes seen as a fixed set of ideas to apply within a school of thinking and practice, such as DDD. Patterns are also seen as something you don't need to know any more because you've got frameworks, libraries and middleware by the download. Or that patterns are something you don't need to know because you're building on diagrams, legacy code or emergent design. All these and more are misconceptions about patterns.

In this workshop, let's take an alternative tour of patterns, one that is based on improving the habitability of code, communication, exploration, empiricism, reasoning, incremental development, sharing design and bridging rather than barricading different levels of expertise. Let's shift the focus from consuming patterns to recognising them, mining them and reasoning through them, with them and about them.
Book your ticket

About us

Our mission is to inspire and educate the working programmers with all degrees of experience in Domain Driven Design and to help them connect. The community in Europe is growing fast, and we provide help and guidance for those who experiment with DDD, and nurish a culture of experimenting, learning and sharing. We believe that software development is about business solutions first, and that we can gain a lot for everyone by bringing the right people together.

Your benefit

Learn how to use Domain Driven Design in your projects directly from acclaimed experts and authors. Tackle complexity in the heart of software. Together with an international cast of DDD practitioners you will strive towards better code, better architecture and better models. We aspire to bring fundamental Domain Driven Design to the hearts and minds of all Developers, Project Managers and Stakeholders.

Venue

H4 Hotel Berlin Alexanderplatz
Karl-Liebknecht-Str. 32
10178 Berlin
Telefon: +49 30 3010411-0
Fax: +49 30 3010411-550
E-Mail: berlin.alex@h-hotels.com.
Location

Hotels

Discover the unique combination of tradition and modernity that surrounds Alexanderplatz. The H4 Hotel Berlin Alexanderplatz (former Ramada Hotel Berlin Alexanderplatz) is located on one of Europe’s most popular squares, just a few steps from the famous Fernsehturm.

For your convinience we recommend residing in the conference Hotel H4 or the adjacent H2. Both hotels have great quality rooms and service and are wheelchair friendly.

Code of Conduct

All attendees, speakers, sponsors and volunteers at our conference are required to agree with the following code of conduct. Organisers will enforce this code throughout the event. We expect cooperation from all participants to help ensure a safe environment for everybody.

Need Help?

You have our contact details in the emails we've sent.

The Quick Version

Our conference is dedicated to providing a harassment-free conference experience for everyone, regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity, religion (or lack thereof), or technology choices. We do not tolerate harassment of conference participants in any form. Sexual language and imagery is not appropriate for any conference venue, including talks, workshops, parties, Twitter and other online media. Conference participants violating these rules may be sanctioned or expelled from the conference without a refund at the discretion of the conference organisers.

The Less Quick Version

Harassment includes offensive verbal comments related to gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity, religion, technology choices, sexual images in public spaces, deliberate intimidation, stalking, following, harassing photography or recording, sustained disruption of talks or other events, inappropriate physical contact, and unwelcome sexual attention.

Participants asked to stop any harassing behavior are expected to comply immediately.

Sponsors are also subject to the anti-harassment policy. In particular, sponsors should not use sexualised images, activities, or other material. Booth staff (including volunteers) should not use sexualised clothing/uniforms/costumes, or otherwise create a sexualised environment.

If a participant engages in harassing behavior, the conference organisers may take any action they deem appropriate, including warning the offender or expulsion from the conference with no refund.

If you are being harassed, notice that someone else is being harassed, or have any other concerns, please contact a member of conference staff immediately. Conference staff can be identified as they'll be wearing branded clothing and/or badges.

Conference staff will be happy to help participants contact hotel/venue security or local law enforcement, provide escorts, or otherwise assist those experiencing harassment to feel safe for the duration of the conference. We value your attendance.

We expect participants to follow these rules at conference and workshop venues and conference-related social events.

Legal Disclosure

Information in accordance with section 5 TMG

KanDDDinsky UG haftungsbeschränkt
Jan Fellien (Geschäftsführender Gesellschafter), Conrad Pöpke und Marco Heimeshoff (Gesellschafter)
Berliner Str. 101
13189 Berlin

Handelsregistereintrag: HRB 197159 B
USt-IDNr: DE318608561

Contact

Telephone: 015201795290
E-Mail: contact@kandddinsky.com

Disclaimer

Accountability for content

The contents of our pages have been created with the utmost care. However, we cannot guarantee the contents' accuracy, completeness or topicality. According to statutory provisions, we are furthermore responsible for our own content on these web pages. In this context, please note that we are accordingly not obliged to monitor merely the transmitted or saved information of third parties, or investigate circumstances pointing to illegal activity. Our obligations to remove or block the use of information under generally applicable laws remain unaffected by this as per §§ 8 to 10 of the Telemedia Act (TMG).

Accountability for links

Responsibility for the content of external links (to web pages of third parties) lies solely with the operators of the linked pages. No violations were evident to us at the time of linking. Should any legal infringement become known to us, we will remove the respective link immediately.

Copyright

Our web pages and their contents are subject to German copyright law. Unless expressly permitted by law (§ 44a et seq. of the copyright law), every form of utilizing, reproducing or processing works subject to copyright protection on our web pages requires the prior consent of the respective owner of the rights. Individual reproductions of a work are allowed only for private use, so must not serve either directly or indirectly for earnings. Unauthorized utilization of copyrighted works is punishable (§ 106 of the copyright law).

Privacy Policy

We are very delighted that you have shown interest in our enterprise. Data protection is of a particularly high priority for the management of the KanDDDinsky UG. The use of the Internet pages of the KanDDDinsky UG is possible without any indication of personal data; however, if a data subject wants to use special enterprise services via our website, processing of personal data could become necessary. If the processing of personal data is necessary and there is no statutory basis for such processing, we generally obtain consent from the data subject.

The processing of personal data, such as the name, address, e-mail address, or telephone number of a data subject shall always be in line with the General Data Protection Regulation (GDPR), and in accordance with the country-specific data protection regulations applicable to the KanDDDinsky UG. By means of this data protection declaration, our enterprise would like to inform the general public of the nature, scope, and purpose of the personal data we collect, use and process. Furthermore, data subjects are informed, by means of this data protection declaration, of the rights to which they are entitled.

As the controller, the KanDDDinsky UG has implemented numerous technical and organizational measures to ensure the most complete protection of personal data processed through this website. However, Internet-based data transmissions may in principle have security gaps, so absolute protection may not be guaranteed. For this reason, every data subject is free to transfer personal data to us via alternative means, e.g. by telephone.

1. Definitions

The data protection declaration of the KanDDDinsky UG is based on the terms used by the European legislator for the adoption of the General Data Protection Regulation (GDPR). Our data protection declaration should be legible and understandable for the general public, as well as our customers and business partners. To ensure this, we would like to first explain the terminology used.

In this data protection declaration, we use, inter alia, the following terms:

2. Name and Address of the controller

Controller for the purposes of the General Data Protection Regulation (GDPR), other data protection laws applicable in Member states of the European Union and other provisions related to data protection is:

KanDDDinsky UG

Berliner Strasse 101

13189 Berlin

Deutschland

Phone: 015201795290

Email: contact@kandddinsky.com

Website: https://kandddinsky.com/

3. Collection of general data and information

The website of the KanDDDinsky UG collects a series of general data and information when a data subject or automated system calls up the website. This general data and information are stored in the server log files. Collected may be (1) the browser types and versions used, (2) the operating system used by the accessing system, (3) the website from which an accessing system reaches our website (so-called referrers), (4) the sub-websites, (5) the date and time of access to the Internet site, (6) an Internet protocol address (IP address), (7) the Internet service provider of the accessing system, and (8) any other similar data and information that may be used in the event of attacks on our information technology systems.

When using these general data and information, the KanDDDinsky UG does not draw any conclusions about the data subject. Rather, this information is needed to (1) deliver the content of our website correctly, (2) optimize the content of our website as well as its advertisement, (3) ensure the long-term viability of our information technology systems and website technology, and (4) provide law enforcement authorities with the information necessary for criminal prosecution in case of a cyber-attack. Therefore, the KanDDDinsky UG analyzes anonymously collected data and information statistically, with the aim of increasing the data protection and data security of our enterprise, and to ensure an optimal level of protection for the personal data we process. The anonymous data of the server log files are stored separately from all personal data provided by a data subject.

4. Subscription to our newsletters

On the website of the KanDDDinsky UG, users are given the opportunity to subscribe to our enterprise's newsletter. The input mask used for this purpose determines what personal data are transmitted, as well as when the newsletter is ordered from the controller.

The KanDDDinsky UG informs its customers and business partners regularly by means of a newsletter about enterprise offers. The enterprise's newsletter may only be received by the data subject if (1) the data subject has a valid e-mail address and (2) the data subject registers for the newsletter shipping. A confirmation e-mail will be sent to the e-mail address registered by a data subject for the first time for newsletter shipping, for legal reasons, in the double opt-in procedure. This confirmation e-mail is used to prove whether the owner of the e-mail address as the data subject is authorized to receive the newsletter.

During the registration for the newsletter, we also store the IP address of the computer system assigned by the Internet service provider (ISP) and used by the data subject at the time of the registration, as well as the date and time of the registration. The collection of this data is necessary in order to understand the (possible) misuse of the e-mail address of a data subject at a later date, and it therefore serves the aim of the legal protection of the controller.

The personal data collected as part of a registration for the newsletter will only be used to send our newsletter. In addition, subscribers to the newsletter may be informed by e-mail, as long as this is necessary for the operation of the newsletter service or a registration in question, as this could be the case in the event of modifications to the newsletter offer, or in the event of a change in technical circumstances. There will be no transfer of personal data collected by the newsletter service to third parties. The subscription to our newsletter may be terminated by the data subject at any time. The consent to the storage of personal data, which the data subject has given for shipping the newsletter, may be revoked at any time. For the purpose of revocation of consent, a corresponding link is found in each newsletter. It is also possible to unsubscribe from the newsletter at any time directly on the website of the controller, or to communicate this to the controller in a different way.

5. Newsletter-Tracking

The newsletter of the KanDDDinsky UG contains so-called tracking pixels. A tracking pixel is a miniature graphic embedded in such e-mails, which are sent in HTML format to enable log file recording and analysis. This allows a statistical analysis of the success or failure of online marketing campaigns. Based on the embedded tracking pixel, the KanDDDinsky UG may see if and when an e-mail was opened by a data subject, and which links in the e-mail were called up by data subjects.

Such personal data collected in the tracking pixels contained in the newsletters are stored and analyzed by the controller in order to optimize the shipping of the newsletter, as well as to adapt the content of future newsletters even better to the interests of the data subject. These personal data will not be passed on to third parties. Data subjects are at any time entitled to revoke the respective separate declaration of consent issued by means of the double-opt-in procedure. After a revocation, these personal data will be deleted by the controller. The KanDDDinsky UG automatically regards a withdrawal from the receipt of the newsletter as a revocation.

6. Routine erasure and blocking of personal data

The data controller shall process and store the personal data of the data subject only for the period necessary to achieve the purpose of storage, or as far as this is granted by the European legislator or other legislators in laws or regulations to which the controller is subject to.

If the storage purpose is not applicable, or if a storage period prescribed by the European legislator or another competent legislator expires, the personal data are routinely blocked or erased in accordance with legal requirements.

7. Rights of the data subject

8. Legal basis for the processing

Art. 6(1) lit. a GDPR serves as the legal basis for processing operations for which we obtain consent for a specific processing purpose. If the processing of personal data is necessary for the performance of a contract to which the data subject is party, as is the case, for example, when processing operations are necessary for the supply of goods or to provide any other service, the processing is based on Article 6(1) lit. b GDPR. The same applies to such processing operations which are necessary for carrying out pre-contractual measures, for example in the case of inquiries concerning our products or services. Is our company subject to a legal obligation by which processing of personal data is required, such as for the fulfillment of tax obligations, the processing is based on Art. 6(1) lit. c GDPR. In rare cases, the processing of personal data may be necessary to protect the vital interests of the data subject or of another natural person. This would be the case, for example, if a visitor were injured in our company and his name, age, health insurance data or other vital information would have to be passed on to a doctor, hospital or other third party. Then the processing would be based on Art. 6(1) lit. d GDPR. Finally, processing operations could be based on Article 6(1) lit. f GDPR. This legal basis is used for processing operations which are not covered by any of the abovementioned legal grounds, if processing is necessary for the purposes of the legitimate interests pursued by our company or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data. Such processing operations are particularly permissible because they have been specifically mentioned by the European legislator. He considered that a legitimate interest could be assumed if the data subject is a client of the controller (Recital 47 Sentence 2 GDPR).

9. The legitimate interests pursued by the controller or by a third party

Where the processing of personal data is based on Article 6(1) lit. f GDPR our legitimate interest is to carry out our business in favor of the well-being of all our employees and the shareholders.

10. Period for which the personal data will be stored

The criteria used to determine the period of storage of personal data is the respective statutory retention period. After expiration of that period, the corresponding data is routinely deleted, as long as it is no longer necessary for the fulfillment of the contract or the initiation of a contract.

11. Provision of personal data as statutory or contractual requirement; Requirement necessary to enter into a contract; Obligation of the data subject to provide the personal data; possible consequences of failure to provide such data

We clarify that the provision of personal data is partly required by law (e.g. tax regulations) or can also result from contractual provisions (e.g. information on the contractual partner). Sometimes it may be necessary to conclude a contract that the data subject provides us with personal data, which must subsequently be processed by us. The data subject is, for example, obliged to provide us with personal data when our company signs a contract with him or her. The non-provision of the personal data would have the consequence that the contract with the data subject could not be concluded. Before personal data is provided by the data subject, the data subject must contact any employee. The employee clarifies to the data subject whether the provision of the personal data is required by law or contract or is necessary for the conclusion of the contract, whether there is an obligation to provide the personal data and the consequences of non-provision of the personal data.

12. Existence of automated decision-making

As a responsible company, we do not use automatic decision-making or profiling.

This Privacy Policy has been generated by the Privacy Policy Generator of the DGD - Your External DPO that was developed in cooperation with German Lawyers from WILDE BEUGER SOLMECKE, Cologne.

Fotohinweise

1. Hinweis auf Ton- und Bildaufnahmen

Bei unseren Veranstaltungen werden von Referenten und Besuchern Aufnahmen in Bild und Ton angefertigt. Diese Aufnahmen können von uns zu Zwecken der Presse- und Öffentlichkeitsarbeit, der Werbung für gleichartige Veranstaltungen und unsere Aktivitäten öffentlich verbreitet und zu journalistischen Zwecken auch an Dritte weitergegeben werden. 

KanDDDinsky UG haftungsbeschränkt
Jan Fellien (Geschäftsführender Gesellschafter), Conrad Pöpke und Marco Heimeshoff (Gesellschafter)
Berliner Str. 101
13189 Berlin

2. Datenschutzinformation gem. Art 13 DSGVO

Datenschutzhinweise zur Verarbeitung von Aufnahmen von öffentlichen Veranstaltungen

Verantwortliche Stelle
KanDDDinsky UG haftungsbeschränkt
Berliner Str. 101, 13189 Berlin
www.kandddinsky.com

Zweck
Anfertigung von Fotos, Bild- und Tonaufnahmen von Veranstaltungen sowie Verbreitung dieser Aufnahmen auf Webseiten, Social-Media-Kanälen sowie in eigenen Printmedien oder zur Weitergabe für redaktionelle und journalistische Nutzungen durch Dritte, zu Zwecken der Presse- und Öffentlichkeitsarbeit und Darstellung der Aktivitäten des Verantwortlichen, um den Bekanntheitsgrad des Verantwortlichen zu erhöhen und für die Teilnahme an vergleichbaren Veranstaltungen und seine Aktivitäten zu werben.

Rechtsgrundlage
Berechtigtes Interesse im Sinne des Art. 6 Abs. 1 lit f DSGVO sowie §§ 22, 23 KUG: Presse- und Öffentlichkeitsarbeit und Darstellung der Aktivitäten des Verantwortlichen, um den Bekanntheitsgrad des Verantwortlichen zu erhöhen.

Widerspruchshinweise
Jeder Betroffene hat das Recht, gegen die Verarbeitung Widerspruch zu erheben. Der Widerspruch kann gerichtet werden an:
orga(at)kandddinsky.com
oder auf jedem anderen Wege ausgeübt werden.

Es ist jedoch in der Abwägung der Interessen davon auszugehen, dass regelmäßig das Interesse des Verantwortlichen an der Anfertigung und Verwendung der Aufnahmen nicht im Übermaß in die Rechte und Freiheiten eines Betroffenen eingreift, da die Bild- und Tonaufnahmen erkennbar und in der „Sozialsphäre“, also im öffentlichen Raum im Rahmen einer allgemein zugänglichen Veranstaltung,  angefertigt wurden und darauf schon in der Anmeldung zur Veranstaltung und bei dieser selbst ausdrücklich hingewiesen wurde. Auch bei der Anfertigung der Bild- und Tonaufnahmen selbst wird darauf geachtet, dass keine berechtigten Interessen von abgebildeten Personen verletzt werden, die Meinungs- und Informationsfreiheit also überwiegt.

Soweit dennoch aus besonderen Gründen im Einzelfall die Rechte und Freiheiten einer abgebildeten Person überwiegen sollten, werden wir im Falle eines begründeten Widerspruchs des Betroffenen die weitere Verarbeitung unterlassen. Eine Unkenntlichmachung in Printmedien, die bereits Verbreitung gefunden haben, kann nicht erfolgen. Eine Löschung von Aufnahmen in Online-Medien erfolgt im Rahmen technischer Möglichkeiten.

Speicherdauer
Die Daten werden nach Beendigung ihrer Nutzung oder spätestens im zweiten Jahr gelöscht. Soweit sie zu historischen Zwecken länger aufbewahrt werden, erfolgt eine entsprechende Beschränkung der Verarbeitung durch Sperrung.

Kategorien von Empfängern
Mitarbeiter des Verantwortlichen, die mit Fragen des Vertriebs-, Marketing oder der Presse- und Öffentlichkeitsarbeit befasst sind oder im Rahmen der Verarbeitung die Daten notwendigerweise erhalten müssen (z. B. IT, sonstige Verwaltungseinheiten, Veranstaltungsorganisation). Auftragnehmer und Auftragsverarbeiter, die bei der Erstellung der Aufnahmen oder der Publikationen oder ihrer Verarbeitung und Verbreitung mitwirken. Sponsoren, Mitveranstalter und Vertreter von Presse und Rundfunk, die zu eigenen bzw. journalistisch-redaktionellen Zwecken über die Veranstaltung und die Aktivitäten des Veranstalters berichten. Steuerberater, Behörden sowie andere rechtlich Beteiligte im Falle der Notwendigkeit einer Durchsetzung von Rechten oder Abwehr von Ansprüchen oder im Rahmen von gerichtlichen oder behördlichen Verfahren.

Die Aufnahmen werden durch Publikationen On- wie Offline an eine allgemeine Öffentlichkeit verbreitet bzw. zum Abruf bereitgestellt. Dabei ist es aus rechtlichen Gründen möglich, dass Dritte eigene Rechte zur Nutzung der Daten geltend machen können, beispielsweise Social-Media-Plattformen Verwertungsrechte oder Journalisten aufgrund Art. 5 GG, die ggfs. Rechten des Betroffenen entgegenstehen können.

Eine Übermittlung an Empfänger in einem Drittland (außerhalb der EU) oder an eine internationale Organisation ist nicht vorgesehen. Eine automatisierte Entscheidungsfindung (Profiling) erfolgt nicht.

Betroffenenrechte
Der Betroffene ist weder vertraglich, noch gesetzlich verpflichtet, seine Daten bereitzustellen. Als von der Verarbeitung von Ton- und Bildaufnahmen betroffene Person steht Ihnen grundsätzlich das Recht auf Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung, Widerspruch und Datenübertragbarkeit im Rahmen der gesetzlichen Bestimmungen zu (Art. 15 ff. DSGVO). Zur Ausübung Ihrer Rechte wenden Sie sich bitte an den Verantwortlichen oder den Datenschutzbeauftragten unter den oben genannten Kontaktdaten.

:speakers_hidden_details: