On this site, there is only displayed the English speaking sessions of the OOP 2021 Digital. You can find all conference sessions, including the German speaking ones, here.
Theme: Domain-Driven Design
- Back to Architecture
- Business Agility
- Design Erosion & Learning from Failure
- DevOps & Continuous Everything
- Diversity & Inclusion
- Domain-Driven Design moving forward
- Full Day Tutorial
- Fusion: IT-Future-Society
- Half Day Tutorial
- Modern C++ Programming
- Modern Enterprise Architecture
- Product Discovery, Customer Centricity & RE
- Signature Track: Back to the Future
- Social Integration
- Special Event
- Testing & Quality
- Trends & Techniques
Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session.
Maximum number of participants: 75
Target Audience: Architects and Developers
Prerequisites: Java Programming
Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session and you will be in a good position to put Reactive to use on your projects. We will start from foundational building blocks and scale up to full Reactive implementations. If you bring your laptop and Java 1.8+ or C# for .NET Core 2.1+ you can try out Reactive during the session.
SOLID principles are well-known for designing object-oriented systems. But what if you are developing microservices? IDEALS, is yet another silly mnemonic acronym and are the core principles for microservice design. The acronym stands for: Interface segregation, Deployability, Event-driven, Availability over consistency, Low Coupling, and Single responsibility. We will relate these IDEALS to techniques, tools, technologies, and domain modeling principles we use today to develop modern service-based distributed systems (microservices).
Target Audience: English, Developers, Architects, QAs, Testers, Product Owners, Managers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
It's been seven years since we've started creating microservices. Practice has shown what design principles give you a sound foundation for a successful microservice architecture. Join us in this session to find out what they are, and how to realize them. For OO systems, Robert Martin compiled the five SOLID principles. For designing microservice-based solutions, we propose developers follow the "IDEALS":
(I) Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs.
(D) Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices.
(E) Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call.
(A) Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they're okay with eventual consistency.
(L) Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling.
(S) Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality.
We will relate these IDEALS to techniques, tools, technologies and domain modeling principles we use today to develop modern service-based distributed systems (microservices).
In an ever increasing need of remote work, we still need to envision new business models, explore our business processes and design our software systems. While nothing can replace the in person collaboration of an EventStorming, remote tools bring their own exciting upsides. During the lock down of the COVID-19 pandemic the DDD community experimented and distilled a collection of remote modelling methods. Let us together dive into some interesting trade-offs and find amazing new tools that carry us into the future.
Target Audience: Senior developers, Software Architects, Facilitators, Consultants, C*Os
Prerequisites: A basic understanding of why we model and how communication influences software would be good
We will explore remote EventStorming, remote Context Mapping with Bounded Context Canvas, architecture design and documentation emerging from and integrated into the model and many more.
Languages that raise the level of abstraction closer to the problem domain help improve quality and productivity. This can be best achieved when the language is directly based on the problem domain, not implementation concepts or existing languages. We describe how to create domain-specific languages in tight collaboration with domain expert users: as soon as a language concept is defined it can be immediately applied by users. We demonstrate this with examples from various fields, such as automotive, home electronics and automation systems.
Target Audience: Developers, subject matter/domain experts, managers
Prerequisites: experiences on applying some modeling language
This talk is based on industry experiences on applying domain terminology directly in a modeling language (in its grammar). This way domain experts can apply familiar terminology, and map the specifications directly to code, to other more technical models, or the same set of models are shared by both domain experts and developers. The talk starts with a practical example how domain experts from different fields can collaboratively edit the same specifications each having own background (industry process, software, hardware, communication). Next the talk describes guidelines how such languages can be created: how domain terminology is defined into a language and how such language can be applied. These guidelines are demonstrated with examples from practice, such as how functional safety engineers can collaborate using ISO26262 (functional safety standard) terminology and related them to the technical system development; and how UX and UI persons can define user interfaces and their behavior in a manner allowing developers to join and work with the same models. The talk is concluded with guidelines and hints backed by industry cases from companies like Panasonic and Elektrobit.
Spaghetti business is difficult enough to swallow without serving a plate of spaghetti architecture and another of spaghetti code. Consider some really hard problems with data and learn how to tackle them with a minimum of technical complexity. Vaughn demonstrates complex business scenarios with solutions using Reactive, DDD, events, and streaming, in a microservices-based distributed system, but with the edges whittled smooth. Join Vaughn as complexity is blown away like wood shavings in a fall wind.
Target Audience: Software Architects, Senior SW Developers, Business Stakeholders with Deeply Complex Problem Spaces
Prerequisites: Experience in software architecture and Interest in finding easy solutions to complex challenges
Distributed Computing: check
Event Sourcing: check
Streaming data: check
Fast data: check
Solution Delivered: not so much
Our industry is strangely fascinated with the new and mysterious, often more so it seems than with delivering business value. Users don’t care about distributed computing, microservices, FaaS, Reactive, CQRS, streaming, or even features. What users care about are outcomes, and checking the technology boxes doesn't deliver outcomes to users. Even simpleton CRUD applications have become overly complicated white elephants bestowed on unsuspecting businesses.
So what happens when the business problem space is complex? Spaghetti business is difficult enough without adding an overdose of architecture and code complexity. It's time for change. Consider some really hard problems with data that we present in government, medical, and financial domains, and learn how to tackle them with a minimum of technical complexity. Events become events become events... Vaughn demonstrates complex business scenarios with solutions using Reactive, DDD, events, event sourcing, CQRS, and streaming, in a microservices-based distributed system, but with the edges whittled smooth. Join Vaughn as complexity is blown away like wood shavings in a fall wind.
DevOps as a software engineering practice unifies software development (Dev) and software operation (Ops). To assist with quality delivery in with DevOps you need to provide a “Quality Delivery Pipeline” to assure the delivery meets the requirements and proper validation and checks are done before releasing into full production. This talk will focus on the “Quality Delivery Pipeline” as a practice that can help sustain delivering with confidence by addressing important qualities in the pipeline.
Target Audience: English, Developers, Architects, QAs, Testers, Product Owners
Prerequisites: Basic Understanding of architecture and microservices and familiarity with DevOps
Many software development processes such as Agile and Lean focus on the delivery of working software that meets the needs of the end-users. Many of these development processes help teams respond to unpredictability through incremental, iterative work cadences, and through empirical feedback. There is a commitment to quickly deliver reliable working software that has the highest value to those using or benefiting from the software. DevOps has become a common practice to assist with quality delivery in these practices, specifically when developing using the microservices architectural style. DevOps as a software engineering practice unifies software development (Dev) and software operation (Ops). To assist with quality delivery in these practices you need to provide a “Quality Delivery Pipeline” to help assure the delivery meets the requirements and proper validation and checks are done before releasing into full production. At the end of the pipeline the validated system will be deployed into production. There are various deployment techniques to help successfully and reliably deploy more quickly. The goal is to give confidence by providing "reliable, working software" to the user (making the user confident in the system). Also, the teams will have more confidence the system is working. This talk will focus on the “Quality Delivery Pipeline” as a practice that can help sustain delivering with confidence by addressing important qualities in the pipeline.
There is an industry trend where businesses are moving towards autonomous product teams. These teams aim to be end-to-end responsible for the product they are building and maintaining. To achieve end-to-end team autonomy, companies move towards a microservices architecture to successfully inspect and adapt. However, to be successful organisations need to have the correct boundaries for the microservices. Using the bounded context pattern from Domain-Driven Design it is possible to achieve team autonomy!
Maximum number of participants: 24
Target Audience: Architects, Developers, Testers, Analysts, Product Owner, Manager, Decision Makers
Prerequisites: None. It is an interactive workshop, with brown paper, post-its and whiteboards
There is an industry trend where businesses are moving towards autonomous product teams. These teams aim to be end-to-end responsible for the product they are building and maintaining. With the help of Continuous Delivery, teams have faster feedback cycles in which they can probe if a certain feature works. To achieve end-to-end team autonomy, companies move towards a microservices architecture to successfully inspect and adapt. To be effective with a microservices architecture, we require Conway's alignment, engineering teams aligned to business models/products; to achieve Conway’s alignment it’s required to design and model the domain. Domain-Driven Design’s bounded context is the essential pattern that helps to create Conway’s alignment.
Join us in this hands-on session where we show you how visual collaboration is the most effective way in co-creating sustainable Conway’s alignment. We will distil bounded contexts with visual collaboration tools Big Picture EventStorming, Context Mapping and the Bounded Context Canvas.
With visual collaboration:
- We create a shared understanding of the business flow, uncovering inconsistencies and competing goals
- Using the Theory of Constraints, we can discover, highlight and create a shared vision and strategy to focus our effort
- A critical part of doing visual collaboration is effective facilitation, especially facilitating workshops with +30 people at the same time
You leave our session understanding that to be effective with microservices, you need to start discover and design bounded contexts. You will learn heuristics that guide you in using visual tools in specific situations, and how to move on towards microservices.