SOFTWARE MEETS BUSINESS:
Die Konferenz für Software-Architektur
08. - 12. Februar 2021, Online-Konferenz
SOFTWARE MEETS BUSINESS:
Die Konferenz für Software-Architektur
08. - 12. Februar 2021, Online-Konferenz
In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design (DDD) nach wie vor ist. Denn nur mit Strategischem Design (also DDD im Großen) und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.
In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Fachexpert:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger
Extended Abstract:
In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design (DDD) nach wie vor ist. Denn nur mit Strategischem Design (also DDD im Großen) und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.
Aber auch Taktisches Design (also DDD im Kleinen) mit der Ubiquitous Language und den "Building Blocks" Entities, Value Objects, Aggregates, Services und Co. haben nichts an Aktualität verloren.
In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.
Der Aufbau wird so sein, dass wir zunächst einen Überblick über DDD geben und uns dann die einzelnen Themen detailliert betrachten. Dabei nähern wir uns DDD gewissermaßen von außen nach innen. Inhaltlicher Aufbau:
Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of “Domain Storytelling – A Collaborative Modeling Method” and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt”.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner
Vortrag Teilen
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
Level: Advanced
Extended Abstract:
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.
Domain-driven Design (DDD) erlebt gerade eine Renaissance: Es ist ein vielversprechender Ansatz für die Modularisierung großer Systeme und für Microservices. In der DDD-Praxis ergeben sich aber oft Missverständnisse und Herausforderungen. Dieser Vortrag greift die typischen Herausforderungen auf und zeigt mögliche Lösungen. Dabei geht es beispielsweise um organisatorische Auswirkungen, das Schneiden von Bounded Contexts, die möglichen Beziehungen zwischen Bounded Contexts und auch die Daten-Konsistenz zwischen Bounded Contexts.
Zielpublikum: Technische Projektleiter:innen, Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Software-Entwicklung
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Durch meine Architektur-Beratungen sehe ich immer wieder Missverständnisse und Probleme bei der Umsetzung von DDD. Ich würde hier gerne Lösungen dafür diskutieren. Mein Ziel ist es, Zuhörer:innen abzuholen, die sich an einer DDD-Architektur versucht haben. Ihnen möchte ich gerne zeigen, wie man typische Probleme löst.
Selbst grundlegende Begriffe wie Bounded Context oder Upstream / Downstream sind schon nicht einfach zu verstehen. Hinzu kommt, dass diese Konzepte Domänenmodelle, organisatorische Elemente und sprachliche Aspekte (Ubiquituous Language) vermengen. Das führt in der Praxis immer wieder zu Herausforderungen. Neben einem Bewusstsein für das Problem möchte ich aufzeigen, dass man diese Aspekte auch getrennt betrachten kann.
Die Strategic Design Patterns wie Conformist oder Customer / Supplier lösen Situationen unterschiedlich. Dazu möchte ich Orientierung und Auswahlkriterien geben. www.heise.de/hintergrund/Grosse-Systeme-mit-Domain-driven-Design-entwerfen-4684074.html zeigt dazu die wesentlichen Ideen.
Daten-Konsistenz wird meistens als Problem wahrgenommen. Wenn man die Domäne genau genug fachlich untersucht, dann ist die Konsistenz oft kein Problem. Dafür möchte ich Beispiele zeigen.
Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff
Vortrag Teilen
Domain Storytelling ist eine Methode für Collaborative Modeling. Sie bringt Fachexpert:innen und Entwickler:innen zusammen und hilft ihnen, die Domäne zu verstehen, Grenzen zwischen Microservices zu finden und über Anforderungen zu sprechen.
Domain Storytelling heißt, dass wir unsere Anwender:innen Geschichten von ihren Aufgaben erzählen lassen. Beim Zuhören zeichnen wir die Geschichten mit einer grafischen Sprache auf.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen, POs
Voraussetzungen: Lust auf ein neues Werkzeug
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Domain Storytelling ist eine Methode für Collaborative Modeling. Sie bringt Fachexpert:innen und Entwickler:innen zusammen und hilft ihnen, die Domäne zu verstehen, Grenzen zwischen Microservices zu finden und über Anforderungen zu sprechen.
Domain Storytelling heißt, dass wir unsere Anwender:innen Geschichten von ihren Aufgaben erzählen lassen. Beim Zuhören zeichnen wir die Geschichten mit einer grafischen Sprache auf.
Unsere Fachexpert:innen können direkt sehen, ob wir sie richtig verstehen und was wir noch falsch verstehen. Nach nur wenigen Stories verstehen wir die Sprache unserer Anwender:innen und können ein Domänenmodell daraus bauen und implementieren.
Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of “Domain Storytelling – A Collaborative Modeling Method” and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt”.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner
Vortrag Teilen
Software ist in nahezu allen Bereichen unseres Lebens unverzichtbar. Neben der Forderung, dass die Software fachlich tut, was sie soll, ist wichtig, dass unsere Softwaresysteme langfristig wartbar und erweiterbar bleiben.
In diesem Talk bekommen Zuhörende Anleitungen, Erkenntnisse, Hinweise und viele Beispiele aus der Praxis, wie die Techniken aus Domain-Driven Design für Softwaresysteme verwendet werden können, die über Jahre gewachsen und möglicherweise ohne Architekturverständnis entwickelt wurden.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Projekterfahrung, Architekturerfahrung
Schwierigkeitsgrad: Fortgeschritten
Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS - Workplace Solutions GmbH und Mitglied der Geschäftsleitung. Seit 1998 entwickelt sie qualitativ hochwertige Softwaresysteme mit ihren Teams. Carola hält regelmäßig Vorträge auf Konferenzen, schreibt Artikel und hat ein Buch zum Thema „Langlebige Software-Architekturen“ veröffentlicht.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal
Vortrag Teilen
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
Level: Advanced
Extended Abstract:
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).
Joseph (Joe) Yoder is president of the Hillside Group and principal of The Refactory. He is best known as an author of the Big Ball of Mud pattern, illuminating fallacies in software architecture. Joe teaches and mentors developers on agile and lean practices, architecture, flexible systems, clean design, patterns, refactoring, and testing. Joe has presented many tutorials and talks, arranged workshops, given keynotes, and help organized leading international agile and technical conferences.
Vortrag Teilen
Im Zuge unseres angestrebten Portfoliowandels hin zu Cloud-native Microservice Architekturen müssen auch wir Berge versetzen. DDD lässt sich in Bestandanwendungen leider nicht direkt in seinem vollen Umfang anwenden. Dennoch helfen die DDD-Methoden und Tools, um die Entwicklungen zielgerichteter und nachhaltiger zu gestalten. Dreh- und Angelpunkt unserer Modernisierung ist das kontinuierliche Optimieren der Bounded Contexts, um motivierte und leistungsfähige Teams zu erreichen. Ich berichte hier von unserem steinigen Weg und unseren Ergebnissen.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Grundverständnis DDD
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Um am Markt mit steigender Digitalisierung und zunehmender Automatisierung erfolgreich bestehen zu können, müssen Unternehmen flexibler und agiler werden. Es ist mehr denn je essenziell, alle laufenden und geplanten Entwicklungsvorhaben effizient und in adäquater Geschwindigkeit abzuschließen.
In diesem Vortrag steigen wir vertiefend in den projektübergreifenden Domain-driven-Design-Ansatz ein. Wir bei DATEV verfügen über eine heterogene Infrastruktur und Produktlandschaft. Die Teamgrenzen und damit die Verantwortungsbereiche entsprechen nicht dem DDD-Idealbild. Die existierende technologische Heterogenität kann nicht auf einen Schlag abgelöst und mittels Microservices realisiert werden. Gerade klassische Infrastrukturen erfordern spezielle Fertigkeiten der Entwicklerteams, die nicht nur auf die Programmiersprache zurückzuführen sind. Folglich ist das Aufarbeiten und Anwenden der DDD-Werkzeuge nicht ganz so geradlinig wie bei „green field“-Projekten. Dennoch müssen auch hier neue, innovative Erweiterungen beispielsweise aus dem Umfeld von Künstlicher Intelligenz oder Big Data eingebracht werden.
Das Gute vorweg: Es lässt sich trotzdem die Architektur (sowohl die der Software als auch der Organisation) sowie die bisher umgesetzte Fachlichkeit im Lichte von DDD beleuchten und abbilden. Viele der geläufigen Methoden wie Event Storming, Domain Storytelling oder Boris Exercise konnten wir gewinnbringend nutzen. Die ermittelten Erkenntnisse lassen sich dazu verwenden, um die weiteren Entwicklungen und Modernisierungen zu platzieren und einzuplanen. Unser Dreh- und Angelpunkt der Modernisierungsvorhaben ist unser Ansatz der weitergefassten Definition des Bounded Contexts. Diese Bounded Contexts dienen uns zur gemeinsamen Diskussion der Abhängigkeiten der Anwendungsteile und natürlich der entwickelnden Teams. Wie sind die Abhängigkeiten und die nötigen Informationen, die miteinander konkretisiert und abgestimmt werden müssen. Wir diskutieren mittels Context Maps, wie die betroffenen Teams anschließend zusammenwirken können. Dabei versuchen wir, durch schrittweise Umorganisation und Verschieben von Fachlichkeit die Autonomie der Teams zu verbessern. Ein kontinuierliches Optimieren der Bounded Contexts ist dabei der eigentliche Weg zu schlagkräftigen, motivierten und leistungsfähigen Teams. Einige dieser Wege, die den umfangreichen und komplexen Domänen in der Legacy-Welt gerecht werden möchten, werde ich aufzeigen und erklären.
Vortrag Teilen
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
Level: Advanced
Extended Abstract:
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.
Vortrag Teilen
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
Level: Advanced
Extended Abstract:
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.
Juha-Pekka Tolvanen works for MetaCase. He has been involved in domain-specific languages and tools since 1991 and acted as a consultant world-wide on their use. Juha-Pekka has co-authored a book (Domain-Specific Modeling, Wiley 2008) and over 100 articles in software development magazines and conferences. Juha-Pekka holds a Ph.D. in computer science.
Vortrag Teilen
Ein halbes Jahrhundert der Software-Entwicklung ist von einem überraschenden Phänomen geprägt: Wir, die Entwickler:innen + Architekt:innen, haben nicht nur immer wieder neue Technologien und Architekturansätze geschaffen, sondern auch Methoden entwickelt, die über die reine Programmierung hinausgehen. Projektleiter, Anwender, Betrieb und Tester haben von unseren Innovationen profitiert. Dieser Vortrag berichtet über die erstaunlichen Beiträge, die unsere Disziplin konzipiert und entwickelt hat, und wagt einen Blick in die Zukunft unserer Disziplin.
Zielpublikum: Alle
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Nach diesem Vortrag werden die Teilnehmenden voller Motivation ihre Reise durch die OOP antreten.
Neben dem Blick in die Vergangenheit wird die Zukunft unserer Disziplin den Schwerpunkt dieses Vortrags bilden.
Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS - Workplace Solutions GmbH und Mitglied der Geschäftsleitung. Seit 1998 entwickelt sie qualitativ hochwertige Softwaresysteme mit ihren Teams. Carola hält regelmäßig Vorträge auf Konferenzen, schreibt Artikel und hat ein Buch zum Thema „Langlebige Software-Architekturen“ veröffentlicht.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal
Unter „Resilienz“ versteht man die Fähigkeit von Systemen, auch unter massiven Störungen von außen ihre Funktionsfähigkeit zu erhalten. Die Coronakrise mit ihren massiven Einschnitten und Opfern hat uns vor Augen geführt, dass Resilienz von Unternehmen entscheidend sein kann für das weitere Überleben. In diesem Vortrag betrachten wir Situationen, in denen Resilienz von besonderer Bedeutung ist, und leiten daraus ab, welche Voraussetzungen Unternehmen erfüllen müssen, um Resilienz zu zeigen. Spoiler: Auch Agilität spielt dabei eine Rolle ...
Zielpublikum: Manager:innen, Entscheider:innen, Organisations-Entwickler:innen, Coaches
Voraussetzungen: Verständnis über Unternehmenssteuerung und Agilität
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Roter Faden dieses Talks ist eine Analogie zwischen der Situation, in der sich Unternehmen während der Coronakrise befanden und noch immer befinden, und den (frei interpretierten) Phasen der Behandlung lebensbedrohlicher medizinischer Notfälle, für die sich in den letzten 50 Jahren weltweite Standards etabliert haben (nein, es wird keine Schockfotos geben. Mir geht es um Taktik und Strategie, nicht um Sensationslust).
Für jede der Phasen (unmittelbare Existenzsicherung, Ursachenfindung, Aufbau von Handlungsoptionen, Ausprobieren der Optionen, Einrichten auf die neue Normalität) wird analysiert, welche Eigenschaften und Praktiken Unternehmen dabei unterstützen oder behindern und wie man sie fördern kann. Dass dabei viele Ähnlichkeiten mit agilen Ansätzen aufscheinen, ist nicht überraschend, wichtig sind aber auch die Bereiche, in denen Agilität alleine nicht ausreicht.
Was hat das mit Tintenfischen zu tun? Diese kommen aus einer Analogie der "Supporting Agile Adoption"-Arbeitsgruppe der Agile Alliance, in der Oktopusse als Beispiel für einen völlig anders organisierten Organismus dienen, der dezentral mit neun Gehirnen kognitive Leistungen erbringt, die sich mit intelligenten Säugetieren messen lassen können. Es zeigt sich, dass die Fähigkeit von Organisationen, Entscheidungen verteilt fällen zu können, ihre Resilienz wesentlich verbessern kann.
Jens Coldewey ist Agilist der ersten Stunde und geschäftsführender Gesellschafter der improuv GmbH. Er hat David Kesby in einem gemeinsamen Projekt kennengelernt und ist beeindruckt von der Klarheit, mit der dessen Konzepte immer wieder auftauchende Probleme adressieren.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/jens.coldewey
Der Trend zu hochskalierenden Cloud-Anwendungen, die auf datengetriebene Features setzen, ist ungebrochen und immer mehr Anwendungen laufen nur noch unter Eventual Consistency. Nebenläufige Änderungen auf inkonsistenten Daten können zu Replikations-Anomalien wie Lost Updates führen, deren Behandlung selbst für erfahrene Software-Architekt:innen eine Herausforderung darstellt. Der Vortrag vereint die neuesten Forschungsergebnisse und Lessons Learned aus mehreren Case Studies mit konkreten Entwurfsmustern für Architekt:innen.
Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Fachkenntnisse Verteilte Systeme, Eventual Consistency, Isolation / Transaktionen
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Der Trend zu hochskalierenden Cloud-Anwendungen, die stark auf datengetriebene Features setzen, ist ungebrochen. Dadurch laufen immer mehr Anwendungen nur noch unter Eventual Consistency. Nebenläufige Änderungsoperationen auf inkonsistenten, replizierten Datenbeständen können allerdings zu schweren Replikations-Anomalien wie Lost Updates führen. Das Implementieren korrekter Merge-Logik im Fall von Schreibkonflikten ist eine große Fehlerquelle und selbst für sehr erfahrene Software-Architekt:innen eine Herausforderung. Basierend auf unseren Erfahrungen aus verschiedenen Case Studies und unserer laufenden Forschung entwickeln wir Architektur-Empfehlungen und Entwurfsmuster für das Design von Anwendungen, die unter Eventual Consistency laufen. Parallel treiben wir die Entwicklung eines Open-Source-Replikations-Frameworks, welches unsere Methoden unterstützt, voran. Der Vortrag gibt konkrete Hilfestellungen für Architekt:innen und beinhaltet eine Demo-Session mit unserer Open-Source-Lösung.
Susanne ist Entwicklerin, Software-Architektin und Forscherin am Fraunhofer IESE. Sie hat mehr als 12 Jahre professionelle Erfahrung und war zunächst für Capgmeini sd&m und die Accso GmbH tätig, bevor sie zu Fraunhofer wechselte. In ihrer PhD erforscht sie wie man zu besseren Software-Architektur-Konzepten für moderne, verteilte Systeme kommt. Sie spricht regelmäßig auf Konferenzen, ist aktives Mitglied der Java User Group Community, Mitglied im Programm-Komitee der JavaLand, Co-Organisatorin der CyberLand Events.
Vortrag Teilen
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
Level: Advanced
Extended Abstract:
Distributed Computing: check
Microservices: check
FaaS: check
Reactive: check
Event Sourcing: check
CQRS: 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.
Vortrag Teilen
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
Level: Advanced
Extended Abstract:
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.
Joseph (Joe) Yoder is president of the Hillside Group and principal of The Refactory. He is best known as an author of the Big Ball of Mud pattern, illuminating fallacies in software architecture. Joe teaches and mentors developers on agile and lean practices, architecture, flexible systems, clean design, patterns, refactoring, and testing. Joe has presented many tutorials and talks, arranged workshops, given keynotes, and help organized leading international agile and technical conferences.
Vortrag Teilen
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
Level: Basic
Extended Abstract:
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.
Vortrag Teilen
In unserem Workshop werden wir:
* Die notwendigen Grundlagen erklären
* Ein kleines Aggregate mittels Event-Sourcing von Grund auf implementieren
* Es wird dabei vorwiegend "test-driven" (TDD) gearbeitet
Voraussetzungen:
* Grundverständnis taktischer DDD Patterns: Value Object, Event, Command, Entity/Aggregate
* Laptop mit IDE und Unit-Test-Framework
* Pair-Programming ist erwünscht
* Der Workshop ist unabhängig von Programmiersprachen
Maximale Teilnehmerzahl: 16
Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundverständnis taktischer Patterns aus DDD: Value Object, Event, Command, Entity und Aggregate
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Event-Sourcing erhält in letzter Zeit viel Aufmerksamkeit, obwohl es beileibe kein neues Architekturpattern ist. Der grundlegende Ansatz, die Änderungen anstatt des aktuellen Zustandes zu speichern, wird seit geraumer Zeit z.B. in der Buchhaltung verwendet. Im Computerzeitalter kommt es unter anderem in den "binlogs" von Datenbanken oder bei GIT zum Einsatz.
Zu den Vorteilen dieses Patterns im Vergleich zu klassischen "Stateful Models" zählen unter anderem:
* leichtere Änderbarkeit des "Code-Models" ohne Datenbankmigration
* Experimente mit alternativen Models
* ein simples Datenbankmodell, das ohne ORM auskommt
* neue Möglichkeiten des Debuggings
* Models mit zeitbasiertem Verhalten
* Auditing
In unserem Workshop werden wir:
* Die Grundlagen von CQRS erklären, da Event-Sourcing ohne CQRS kaum möglich ist
* Erklären, was ein "Aggregate" eigentlich ist
* Ein kleines Aggregate mittels Event-Sourcing von Grund auf implementieren, inklusive einiger "Events", "Commands" und "Value Objects"
* Unsere Grundlage dafür wird das Ergebnis einer (fiktiven) "Event Storming" Session sein
* Wir werden dabei "test-driven" (TDD) arbeiten, um nur zu implementieren, was auch wirklich benötigt wird
Voraussetzungen:
* Die Teilnehmenden des Workshops sollten ein Grundverständnis taktischer Patterns aus Domain-driven Design mitbringen: Value Object, Event, Command, Entitiy und Aggregate
* Der Workshop ist grundsätzlich unabhängig von Programmiersprachen
* Die Coaches können: Golang, Java, C# und PHP und haben ein Grundverständnis funktionaler Programmierung
* Die Teilnehmenden sollten einen Laptop mit ihrer liebsten IDE und einem installierten Unit-Test-Framework mitbringen
* Pair-Programming mit anderen Teilnehmenden ist selbstverständlich auch möglich
Vortrag Teilen