Herausforderungen und realisieren gemeinsam die Zukunft. Wir unterstützen unsere Kunden mit innovativen Vorgehensmodellen und den aktuellsten Technologien. MISSION 26 Jahre Erfahrung 300+ IT-Expert*innen 30 Digitalisierungs- expert*innen 13 Partner 27 Entwicklungs- projekte parallel BONN BERLIN KÖLN BUKAREST 5 Standorte +
Bergen • Seit über 11 Jahren bei der tarent • Java, Kotlin, Scala, Go, Docker, Kafka, Cloud & alles was Bleeding Edge ist • @chris__schmidt • https://github.com/darktoast • https://gitlab.com/christian_schmidt
at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1$1.invoke(RequestConverter.kt) at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1$1.invoke(RequestConverter.kt) at io.ktor.server.application.OnCallReceiveContext.transformBody(KtorCallContexts.kt:65) at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1.invokeSuspend(RequestConverter.kt:22) at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1.invoke(RequestConverter.kt) at io.ktor.server.plugins.contentnegotiation.RequestConverterKt$convertRequestBody$1.invoke(RequestConverter.kt) at io.ktor.server.application.PluginBuilder$onCallReceive$3.invokeSuspend(PluginBuilder.kt:165) at io.ktor.server.application.PluginBuilder$onCallReceive$3.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onCallReceive$3.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onCallReceive$2.invokeSuspend(PluginBuilder.kt:109) at io.ktor.server.application.PluginBuilder$onCallReceive$2.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onCallReceive$2.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhase$1.invokeSuspend(PluginBuilder.kt:217) at io.ktor.server.application.PluginBuilder$onDefaultPhase$1.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhase$1.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1$1.invokeSuspend(PluginBuilder.kt:200) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1$1.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1$1.invoke(PluginBuilder.kt) at io.ktor.util.debug.ContextUtilsKt.addToContextInDebugMode(ContextUtils.kt:30) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1.invokeSuspend(PluginBuilder.kt:196) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1.invoke(PluginBuilder.kt) at io.ktor.server.application.PluginBuilder$onDefaultPhaseWithMessage$1$1.invoke(PluginBuilder.kt) at io.ktor.util.pipeline.DebugPipelineContext.proceedLoop(DebugPipelineContext.kt:80) at io.ktor.util.pipeline.DebugPipelineContext.proceed(DebugPipelineContext.kt:57) at io.ktor.util.pipeline.DebugPipelineContext.execute$ktor_utils(DebugPipelineContext.kt:63) at io.ktor.util.pipeline.Pipeline.execute(Pipeline.kt:77) at io.ktor.server.request.ApplicationReceiveFunctionsKt.receive(ApplicationReceiveFunctions.kt:88) at de.tarent.crud.controller.GroupsKt$groupPage$1$3.invokeSuspend(groups.kt:97) at de.tarent.crud.controller.GroupsKt$groupPage$1$3.invoke(groups.kt)
• voll integrierte Systemlösung • IBM-POWER 9 CPUs • OS/400 bzw. i5/OS • Fest integrierte OS/2 for i Datenbank • Fest integriertes IAM per IBM Directory Server for IBM i (LDAP) • Entwicklung in RPG • Greenscreen Applikation
◦ Core Domain Die Kernkompetenz der Unternehmung z.B. in einer Werkstatt die Planung der Reparaturen ◦ Supporting Domain Unterstützt die Core Domain, hat aber weniger Priorität. z.B. im eCom Bereich die Auswertung von Bestellungen ◦ Generic Domain kann gut durch gekaufte Software umgesetzt werden. z.B. Buchhaltung, Projektplanung
◦ Der Bounded Context als “Lösungsraum” - umfasst nie die gesamte Subdomain! ◦ Ideal: Pro Subdomain ein Bounded Context • Optimal ein Team pro Bounded Context
Bereich. Fachlich, wie technisch. • Ein Team allein kümmert sich um den Bounded Context. • Kommunikation zwischen Bounded Context passiert über Domain Events oder Commands • Dem Team stehen entsprechende Domainexperten zur Verfügung um gemeinsam die Subdomain zu erfassen. • Nie in Stein gemeißelt! Auch ein Bounded Context kann sich ändern
Context arbeiten an einem gemeinsamen Ziel. Enge Zusammenarbeit, kurze Kommunikation. • Customer Supplier Losere Kopplung als Partnership. Der “Supplier” Ist der Upstream, der Customer der Downstream. Beide Besprechen den Austausch, der Upstream bestimmt aber schlussendlich, was geschieht. • Shared Kernel Beide Contexte, bzw. Teams teilen sich einen Teil des Modells. Z.B. als Library etc. Enge Zusammenarbeit, Gefahr der “Ausfransung” des Modells. • Conformist Wie Customer Supplier. Der Downstream Host hat aber keine Entscheidungsmöglichkeit auf den Upstreamhost und muss mit dem Modell leben. Z.B. als Anbindung an eine “fremde” API. U D U D
bei dem der Downstream das Upstream Modell und damit die ubiquitous language in das eigene Modell umwandeln und nicht direkt nutzt. Gut zur Integration “fremder” APIs. • Open Host Service Der Bounded Context bietet eine öffentliche, gut dokumentierte API an jeden “interessierten” Context an. Kann als “wohlwollender” Gegenpart zum Conformist-Pattern gesehen werden. • Published Language Ähnlich zum Open Host Service. Das Austauschformat, hier Language, wird als Schema (Json, XML), etc. dokumentiert hinterlegt. Basis für z.B. Contract Driven Testing D A C L O H S P L
die entweder unvollständig implementiert ist oder aber der Integrationsaufwand den Nutzen nicht rechtfertigt, macht es ggf. Sinn die Funktionalität des anderen Context nachzubauen. • Big Ball of Mud Kein Design, aber oftmals die Realität. Verschiedene logische Contexte wurden ineinander verschachtelt und ohne eine passende Strategie verwebt und genutzt.
durch Events oder Commands • Events sind passiv. ◦ “Hier ist etwas passiert. Du kannst es behandeln” • Commands sind aktiv. ◦ “Ich möchte, dass du etwas tust!” • Nicht verwechseln mit synchroner und asynchroner Kommunikation! Event: “Customer updated” Command: “Update customer”
Context und Subdomains • Ein einzelner Context wird herausgelöst • Identifizierung der Relation • Eine Anbindung mindestens mit dem Anti-Corruption Layer. Das eigene Modell sollte nie mit dem “Modell” des BBoM “kontaminiert” werden.
Systemlandschaft ◦ Context Map ◦ Strategic Design Pattern ◦ Ubiquitous Language • Per Domain Events und Commands existieren Austauschtechniken ◦ Asynchron ◦ Synchron • Aber: ◦ DDD ist nur ein Werkzeug im Werkzeugkasten ◦ Das Herauslösung von Codeteilen ist nicht trivial! ◦ Ein Bounded Context sollte nie in Stein gemeißelt sein!
darktoast
moulongzhang
iotcomjpadmin
isaoshimizu
nari_ex
miichan
cheng_wei_chen
uhyo
ninomiya_ii
kozy4324
taka_aki
freshdaz
nagatsu
dugsong
badams
palkan
addyosmani
mfonobong
pauljervisheath
jacobian
portentint
baasie
andyhume
eileencodes
rabernat
![CONWAYS LAW “Organizations which design systems […] are constrained to](https://files.speakerdeck.com/presentations/6b2377ccc0b4489696563866eedd3431/slide_23.jpg){kind=link}
![UBIQUITOUS LANGUAGE “customer”: { “name”: “Max”, “surname”: “Mustermann”, “email”: “[email protected]”,](https://files.speakerdeck.com/presentations/6b2377ccc0b4489696563866eedd3431/slide_27.jpg){kind=link}
