Domain-driven Design – Praxis, Austausch, neue Impulse

Domain-Driven Design (DDD) ist weit mehr als ein Architektur- oder Modellierungsansatz – es ist eine gemeinsame Sprache, ein «Thinking Framework» und oft der Schlüssel zu erfolgreichen und nachhaltigen Softwarelösungen. Gleichzeitig wirft DDD in der Praxis einige Fragen auf:

Was funktioniert wirklich? Wo stößt der Ansatz an Grenzen? Und wie gelingt die Zusammenarbeit zwischen Business Stakeholders und IT Professionals?

Diesen und weiteren Fragen möchten wir uns in diesem SITIC Sharing mit Keynotes und interaktiven Mini-Workshops zum Thema Domain-Driven Design widmen.

Domain-driven Design + Artificial Intelligence = ?

Und auch die allgegenwärtige Frage einbeziehen, ob und wie KI-Anwendungen DDD mitbestimmen.

Ziel des Sharings ist es nicht, ein «richtig» oder «falsch» zu definieren, sondern voneinander zu lernen, Denkanstöße mitzunehmen und neue Impulse für die eigene Organisation zu gewinnen.

Die folgenden Leitfragen stehen im Mittelpunkt dieses Sharings:

1. Warum haben sich SITIC-Mitglieder strategisch für oder gegen Domain-driven Design entschieden und was waren die aus dieser Entscheidung resultierenden Konsequenzen und Erfahrungen?
2. Inwieweit eignet sich Domain-driven Design als Grundlage zur Erstellung einer umfassenden Business Architecture?
3. Welche Best Practices, Tools und Techniken haben sich bei der Anwendung von Domain-driven Design, also der Definition von Subdomains bzw. Bounded Contexts und deren Entwicklung und Pflege, bewährt?
4. Welche Wechselwirkungen bestehen zwischen Domain-driven Design und dem Einsatz von AI im Unternehmen und wie können sie sich gegenseitig positiv beeinflussen?
5. Welche organisatorischen Voraussetzungen oder Änderungen unterstützen eine erfolgreiche Anwendung von Domain-driven Design? Welche Rollen/Kompetenzen/Governance braucht es grundsätzlich?
6. Wie integrieren SITIC-Mitglieder Domain-driven Design in die Prozesse der Strategieentwicklung und des Projekt-Portfolio-Managements? Was ist die Rolle der Enterprise Architecture im Kontext von DDD und welche Ansätze empfehlen sich für die Architektur-Governance?
7. Wie gelingt der Einstieg in Domain-driven Design (inkl. Stolpersteine) und woran erkennt man, ob Domain-driven Design im Unternehmen erfolgreich eingesetzt wurde?
8. Wie kombiniert man «DDD-Thinking» mit nicht-deterministischen KI-Modellen? Wie kann man probabilistische KI-Ergebnisse innerhalb eines streng modellierten Domänenkontexts sinnvoll nutzen, ohne die fachlichen Regeln zu verletzen?

Gastgeber
Alexander Eisgruber, Swisscard AECS

Lokation
Swisscard AECS GmbH, Neugasse 18, CH-8810 Horgen

Anreise und Parkmöglichkeit
Angaben folgen.

Willkommen sind sowohl Business Stakeholders als auch IT Professionals, welche in grösseren IT-Anwender-Organisationen die Aufgaben der Digitalisierung, Geschäftsentwicklung, Unternehmens und IT-Architektur, Compliance, wahrnehmen und DDD bereits einsetzen oder sich intensiver damit auseinandersetzen möchten.

Kurt Wehrli, SITIC Vorstandsmitglied

09:30 – 10:00
Eintreffen der Teilnehmenden, Willkommenskaffee

10:00
Eröffnung und Einleitung
Kurt Wehrli, SITIC

10:10
Grusswort von Frau Linda DeWinter
CIO, Swisscard AECS

10:20
External Keynote
DDD bringt nix – ausser man lebt es
Christian Stettler, INNOQ

Christian works as Senior Consultant and Architect at INNOQ in Switzerland. Since 15+ years he is involved in designing and implementing business-critical systems using distributed, scalable architectures. He is a DDD enthusiast and determined to leverage the principles of Domain-Driven Design for gaining deep business understanding and putting this understanding in readable code.

Internal Keynote
Disintegrating a Data Integration Platform – Modularizing the Monolith
Alexander Eisgruber, Swisscard AECS

Member Contributions

< Title >
< Speaker >
< Abstract >

< Title >
< Speaker >
< Abstract >

12:15
Sandwich-Lunch & Networking

13:15
< Title >
< Speaker >
< Abstract >

< Title >
< Speaker >
< Abstract >

14:15
Pause und Mini-Workshops

15:15
Plenumsdiskussion

15:45 – 16:00
Ausblick und Abschluss

16:00
Farewell-Apéro

Eine Nachlese wird auf Wunsch der Teilnehmenden erstellt.

Verbindliche Anmeldung bitte via Email an kurt.wehrli@sitic.org

Für SITIC-Mitglieder ist die Teilnahme im Rahmen der Jahresmitgliedschaft unentgeltlich.
Nicht-Mitgliedern aus IT-Anwender-Organisationen werden 750 CHF in Rechnung gestellt.

Domain-driven design (DDD) is a valuable approach to software development, especially for complex environments where decentralized control exists, or where there are many interconnected parts or components that interact in less predictable ways. Instances where DDD is well suited include situations with multiple stakeholders or highly matrixed organizations where improved communications and collaboration are needed. Perhaps the biggest benefit of DDD is close collaboration between domain experts (business or functional teams) and developers, enabling a shared understanding of the domain and alignment of organizational goals to be achieved. Another benefit is that DDD can address simplification of disparate or legacy systems that have a history of quick fixes that adding a layer of complexity that can be addressed with a better, more efficient process. [Reference]

DDD ist an keinen bestimmten Software-Entwicklungsprozess gebunden, orientiert sich aber an agiler Software-Entwicklung. Insbesondere setzt es iterative Software-Entwicklung und eine enge Zusammenarbeit zwischen Entwicklern und Fachexperten voraus. [Wikipedia]

By combining knowledge graphs, automated schema generation, and domain-driven design, Netflix tackles the problem of fragmented data models that plague large-scale distributed systems. [Reference]

Developer platforms are supposed to defy the IT laws of physics: they boost innovation through harmonisation; they speed up development while assuring compliance; and they reduce cognitive load without restricting choice. But how exactly are they doing that? Does providing sane defaults or templating a golden path really abstract away cognitive load? Successful platforms do one thing well: they abstract technical complexity by providing a domain-specific language for developers. That language maps back to cloud automation, reference architectures, and, indeed, golden paths. Let’s explore how DDD plays a critical role in Platform Engineering here.

In this video, let’s learn the basics of Domain Driven Design, or DDD and understand what really is a «bounded context», which is so often used incorrectly to be a «service».