Recommended
Recommended
More Related Content
Similar to DDDEU '19 rewind
Similar to DDDEU '19 rewind (20)
Recently uploaded
Recently uploaded (20)
DDDEU '19 rewind
- 1. DDDEU ‘19 Rewind Kostas Stroggylos @sparcular
- 3. Day #1
- 4. Opening ceremony: DDD The first 15 years
- 5. Keynote: Eric Evans The level of rigor depends on the context Defining DDD, 15 years later
- 6. Adam Tornhill - Source code repositories: a goldmine of behavioral data - Refactor in isolation - Write tests in the language of the domain Guiding refactoring with behavioral code analysis
- 7. Cyrille Martraire Modeling should be guided by first principles 1. Conceptualize a model as a theory 2. Identify first principles behind it 3. Challenge them 4. Digital Transformation!!! Domain modeling towards first principles
- 8. Nataliya Remez Deliver better outcomes, not increased output The (digital) transformation is not as important as solving the business problems Proper organizational structure must be in place to support such attempts Product strategy is a hypothesis that needs to be validated and refined continuously The journey to outcome-oriented teams
- 9. Jérémie Chassaing Definition of what is near or far has changed Concurrency issues are business decisions, not technical ones Do things asynchronously instead of blocking until all the data is available Information space-time
- 10. Day #2
- 11. Maaret Pyhäjärvi Testing does not break your code, it breaks your illusions about the code Cognitive dissonance => illusions about the systems we build Serendipity & perseverance: superpowers, core of exploring & learning Keynote: Breaking illusions with testing
- 12. Anita Sengupta How do you test code running in a rover deployed to Mars? Serious challenges are crucial to provoke out of the box thinking and lead to innovation Closing Keynote: The humans exploration of Mars
- 13. Thanks!
Editor's Notes
- It has been 15 years since the Blue Book was published, and a lot has happened since then. Matthias Verraes opened the day surprising Eric Evans on stage with a new book. It is titled Domain Driven Design: The first 15 years, and is comprised of 15 articles by various authors. It is freely available here and is already on my reading list.
- DDD lies somewhere in-between mathematics and happiness, and concluding with his insights on what he thinks its value is today. He discussed how microservices are a hot topic nowadays, as they are the biggest opportunity and the biggest risk the software engineering community has had in a long time. At the same time, we need to avoid negative connotations on “legacy” systems. An idea to avoid throwing away their value and allow them to take part in the action is to expose assets through them and thus allow them to participate in microservice protocols. The most interesting takeaway from his talk however was that context is key: the level of rigor depends on the context. In some contexts rigor is intended, whereas in others it’s not a priority. That’s why company-wide (coding/architecture/technology) policies tend to be a failure.
- Leverage data from code repositories to uncover areas in the codebase that may indicate issues like excess complexity and indirect dependencies. The most interesting idea proposed is refactoring of problematic areas in isolation to reduce accidental complexity before moving the improved code back into its original location, taking the chance to write tests in the language of the domain. it’s the features that need to drive architectural building blocks, not technology
- He challenged technical assumptions - e.g. he said you can vary the implementation style inside each bounded context. He also mentioned business dysfunctions, such as the human compiler anti-pattern. The key takeaway is that we need to conceptualize a domain model as a theory, identify the first principles behind it, and challenge them to suggest changes in the business processes. This “raises the waterline”, leading to innovation. Otherwise we are left with solution envy, a state where everyone wants to be the problem ‘solver’ even if it’s not their job or their skills cannot support this.
- how to transform teams so that they deliver better outcomes vs increased output. An example that hits home for DH is modeling a feature as pizza - pizza is an output, but we should target a quality outcome: delivering pizza warm, on time, just like the customer wants it. I identified many themes presented in the book Accelerate which I had recently read. Nataliya discussed why most agile transformations fail. She says the transformation itself is not as important as solving the business problems. These attempts collapse under the weight of complexity if there is no proper organizational culture in place to support them. The key takeaway for me was that Product Strategy is actually a hypothesis that needs to be validated and refined continuously by collecting measurable signals.
- Τime and how it has affected business from centuries ago up to now. He focused especially on how the definition of what is near or far has changed over the years and how speeding up operations like communication and transport has changed the game. The thing to keep in mind is that concurrency issues are (or should be) mostly business decisions, not technical ones. We need to solve issues from the business rather than the technical perspective. Doing things asynchronously is often better than blocking things, waiting until we have all the data available to make a fully informed decision.
- She described some illusions we have about the code we write and the products we build, and offered some heuristics that can be used to break them. She analyzed how cognitive dissonance, a term I had come across when reading the excellent book Black Box Thinking by Matthew Syed, can lead to these illusions. She then presented one of the most discussed slides in the whole conference, containing a controversial opinion on what continuous delivery means.
- a serious challenge, like sending people to Mars, is crucial to provoke out of the box thinking that will leverage past knowledge to push the boundaries of technology.