Ten years ago I joined a small company with 25 people that is now part of a group with over 5000 people. Therefore, scaling, changing and transformation are topics that are part of my routines.
Four years ago I discovered Domain-Driven Design and it was a game changer. Something that could tackle complexity and engage team members at their full capabilities; having techniques that project realities to enable clear perceptions of the business – that was exactly what I was looking for. I’m proud to say that I have experimented a lot with team dynamics, strategic design and advanced architecture topics lately; and the outcomes are usually very satisfying and worth sharing.
Having worked in sectors like e-commerce, governance and industry, I’m currently Engineering Manager for the Real Estate classifieds domain.
Sessions Lisbon 2020
Eric Evans states that technology is just a way to solve problems, it’s a choice. The real complexity in software design is in the domain and we should handle it continuously. This is an observation that immediately caught our attention.
DDD’s defined principles and practises can change the way we use to approach software projects. In fact, I had the privilege to apply some of these techniques and the results were noticeable.
When complexity increases, developers can no longer understand the software. Domain-Driven Design provides a set of guidelines and techniques to tackle this issue. It’s a business oriented discipline in which its primary focus is the core domain. So, what is this all about?
Two years ago, I started to read Domain-Driven Design, Tackling Complexity in the Heart of Software. This book changed my life as an engineer and this session is about its story.
It starts with conceptual definitions. What is a model? What does it give to us?
It continues with a set of guidelines on how to build complex applications without compromising responsibilities and structure, just by applying a small set of building blocks and patterns that are easy to understand and complement so well with other well-known methodologies.
Finally, Strategic Design. What if we have to deal with huge systems with huge teams? How can we transform it so it becomes easier to maintain? Normally precision does not survive in the long term, there’s too much to interact with and “only a part of a big system will be well designed”.
This session will address technical topics like entities and value objects and more strategic topics like the importance of language and bounded contexts. Everything will be supported with examples to make some of these abstract concepts easier to understand.
Event Storming workshop
Self organization is not guaranteed to happen. People normally won’t organise around a system that they don’t understand or a system they can’t influence.
Silos exist everywhere. This reality maximises the overall ignorance within organisations: business flows span across several areas of expertise and a single source of knowledge won’t be enough to solve problems. Event Storming can expose conflicts and contradictions happening at the boundaries between these silos.
EventStorming as described by its creator, Alberto Brandolini, is a meeting where all the project’s key stakeholders should be present. It serves to identify flows, problems and all the important components for a certain application. Everyone will use sticky notes to identify Domain Events, Commands, External Systems, Policies and other units in a timeline that will allow composing a complex model of the system. It’s an exploratory process where stakeholders interact between themselves. Bottlenecks, improvements or critical issues can be discovered by looking at the model originated in these EventStorming sessions.
EventStorming is a flexible process. As its creator author states, it’s like Carbonara – no matter the recipe variation, it’s always good.
During this session we will go through some EventStorming basics and we will have the opportunity to try this approach with a small example.