[et_pb_section fb_built=”1″ _builder_version=”4.6.5″ _module_preset=”default” custom_padding=”30px||0px||false|false”][et_pb_row column_structure=”1_4,3_4″ _builder_version=”4.7.3″ _module_preset=”default” background_color=”#ffffff” custom_margin=”|||-15px|false|false” custom_margin_tablet=”” custom_margin_phone=”” custom_margin_last_edited=”on|tablet” custom_padding=”0px||4px||false|false” locked=”off”][et_pb_column type=”1_4″ _builder_version=”4.7.3″ _module_preset=”default”][et_pb_image src=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2020\/03\/Feix.png” alt=”Feix” title_text=”Feix” show_in_lightbox=”on” src_tablet=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2020\/03\/Feix.png” src_phone=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2020\/03\/Feix.png” src_last_edited=”on|phone” _builder_version=”4.7.3″ _module_preset=”default” width=”40%” width_tablet=”15%” width_phone=”25%” width_last_edited=”on|phone” custom_margin=”10px|||15px|false|false”][\/et_pb_image][\/et_pb_column][et_pb_column type=”3_4″ _builder_version=”4.7.3″ _module_preset=”default”][et_pb_toggle title=”Axel Feix” open_toggle_background_color=”#ffffff” closed_toggle_background_color=”#ffffff” icon_color=”#f3f3f3″ _builder_version=”4.7.3″ _module_preset=”default” title_text_color=”#003f86″ title_level=”h2″ title_font=”||||||||” title_letter_spacing=”1px” body_font_size=”16px” custom_margin=”15px|||-105px|false|false” custom_margin_tablet=”9px|||18px|false|false” custom_margin_phone=”|||15px|false|false” custom_margin_last_edited=”on|desktop” custom_padding=”20px|||0px|false|false” custom_padding_tablet=”0px||||false|false” custom_padding_phone=”” custom_padding_last_edited=”on|desktop” border_width_all=”0px”]<\/p>\n
Axel Feix hat langj\u00e4hrige Projekterfahrung als Analyst und Softwarearchitekt. Er unterst\u00fctzt Kunden als Senior Consultant und Trainer bei der Einf\u00fchrung und Umsetzung von Software-Engineering, Requirements-Engineering, Softwarearchitektur-Management und Architekturdokumentation. Er interessiert sich f\u00fcr was fliegt, alles was man visualisieren und spielen kann, und was die Welt zusammenh\u00e4lt.<\/p>\n<\/div>\n
[\/et_pb_toggle][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.7.3″ _module_preset=”default”][et_pb_column type=”4_4″ _builder_version=”4.7.3″ _module_preset=”default”][et_pb_text _builder_version=”4.7.3″ _module_preset=”default” link_font=”||on||||||” custom_padding=”29px|||||”]<\/p>\n
Microservices und Domain Driven Design (DDD)<\/a> z\u00e4hlen nach wie vor zu den Hype-Themen der IT-Szene. Ein paar Sekunden Google-Suche reichen aus, um gleich Dutzende Artikel ausfindig zu machen, die wahre Loblieder auf die \u201eLiebesbeziehung\u201c von Microservices und Bounded Contexts singen. Aber ist das wirklich so? Passen Microservices und Bounded Contexts wie Topf und Deckel zusammen oder wird das Thema vielleicht doch zu sehr durch die rosa Brille findiger Consultants betrachtet?<\/p>\n [\/et_pb_text][et_pb_text _builder_version=”4.7.3″ _module_preset=”default” link_font=”||on||||||” header_2_letter_spacing=”2px” custom_margin=”||||false|false” custom_padding=”20px||||false|false”]<\/p>\n Domain Driven Design (DDD) ist als ein Konzept entstanden, um die Distanz zwischen den Dom\u00e4nen-Experten und dem Software-Entwicklungsteam und die daraus resultierenden Projektrisiken nachhaltig zu verringern. Eric Evans hat das in seinem Standardwerk \u201eDomain-Driven Design: Tackling Complexity in the Heart of Software\u201c pr\u00e4zise beschrieben. Ein zentrales Element ist dabei eine gemeinsame Fachsprache, die \u201eUbiquitous Language\u201c<\/a>, die aus der Dom\u00e4nen-Story entwickelt und auf allen Ebenen vom Grobkonzept bis in den Quellcode hinein als Vokabular angewendet wird. In den meisten F\u00e4llen zeigen sich bei der Herleitung der Domain-Story einige Begriffe, die in unterschiedlichen Zusammenh\u00e4ngen (z. B. Fach-Abteilungen) andere Bedeutungen haben. Im Domain Driven Design (DDD) wird in diesem Fall keine sprachliche L\u00f6sung geschaffen, sondern eine Grenze um den maximalen Raum innerhalb der Dom\u00e4ne gezogen, in dem jeder Fachbegriff eine eindeutige Bedeutung hat. Dieser abgegrenzte \u201eSprachraum\u201c ist der Bounded Context<\/em>.<\/p>\n [\/et_pb_text][et_pb_text _builder_version=”4.7.3″ _module_preset=”default” header_2_letter_spacing=”2px” custom_margin=”||||false|false” custom_padding=”20px||0px||false|false”]<\/p>\n Aus dieser Perspektive wird klar, dass ein Bounded Context <\/em>\u2013 je nach Komplexit\u00e4t der Dom\u00e4ne \u2013 ganz unterschiedliche Dimensionen annehmen kann. Die Spanne erstreckt sich von einem sehr kleinen Kontext, der sich durchaus zur Abgrenzung eines Microservice eignen kann, bis hin zu einem gewaltigen, als Microservice untauglichen Kontext-Monolithen. In den meisten F\u00e4llen sind Microservice und Bounded Context folglich ein ausgesprochen ungleiches Paar. Der Bounded Context beschreibt die maximale Ausdehnung, die ein Microservice logisch annehmen kann, und steht damit geradezu im Widerspruch zu dessen Anforderungen an reduzierte Komplexit\u00e4t und Gr\u00f6\u00dfe. Es ist aber deutlich zu sagen: Ein Bounded Context ist kein Microservice. Ein Microservice ist technisch und stelle eine Deployment Grenze dar. Ein Bounded Context ist dagegen eine fachliche Sprachgrenze mit einer klaren Definition f\u00fcr jeden Begriff. Die Gr\u00f6\u00dfe und Form eines solchen Contexts wird durch die strategische Planung, die Komplexit\u00e4t des Modells und die Teamstruktur bestimmt.<\/p>\n Bounded Contexts sind eine M\u00f6glichkeit, erste Schnitte im Projekt anzusetzen und bieten damit zumindest eine Ann\u00e4herung. Zum anderen ist jeder Bounded Context ein Cluster, in dem mehrere zu definierende (Micro-)Services durch die Ubiquitous Language logisch verbunden sind. Auch das kann bis hin zur Evolution der Microservice-Landschaft eine Menge Vorteile bringen.<\/p>\n [\/et_pb_text][et_pb_text _builder_version=”4.7.3″ _module_preset=”default” header_2_letter_spacing=”2px” custom_margin=”||||false|false” custom_padding=”20px||||false|false”]<\/p>\n Die DDD bietet einen ganzen Baukasten an Werkzeugen an, um strategisches und taktisches Domain Driven Design zu betrieben. Beim strategischen DDD sind das z. B. Dave Snowdens \u00a0Komplexit\u00e4tsanalyse nach Cynefin, Dom\u00e4nenmodelllierung mit Aberto Brandolinis Event Storming, Exploration mit Hilfe von Simon Wardleys Wardley Mapping, Strategische Entkopplung durch Eric Evans Bounded Context Mapping oder System Thinking nach Donella Meadows. Diese Werkzeuge zu kennen und erfolgreich einzusetzen ist essenziell f\u00fcr den erfolgreichen Einsatz DDD und Microservices.<\/p>\n F\u00fcr die Microservices selbst und deren Abgrenzung stellt Domain Driven Design das Konzept der internen Bausteine (Internal Building Blocks) mit vielen n\u00fctzlichen Patterns zur Verf\u00fcgung. Das vielleicht wichtigste dabei sind die Aggregates<\/em>, die als kleinste sinnvolle Einheit f\u00fcr einen Microservice sozusagen den Gegenpol zu den Bounded Contexts bilden.<\/p>\n [\/et_pb_text][et_pb_text _builder_version=”4.7.3″ _module_preset=”default” header_2_letter_spacing=”2px” custom_margin=”||||false|false” custom_padding=”20px||||false|false”]<\/p>\n Anhand dieser Betrachtungen l\u00e4sst sich klar sagen: Auf der Ebene von Microservices und Domain Driven Design passt der Deckel ganz klar auf den Topf! Bounded Contexts sind f\u00fcr diesen Bund ein wertvoller Beitrag \u2013 unter vielen anderen.<\/p>\n [\/et_pb_text][et_pb_text _builder_version=”4.7.3″ _module_preset=”default” link_font=”||on||||||” header_2_letter_spacing=”2px” custom_margin=”||||false|false” custom_padding=”18px||||false|false”]<\/p>\n Einen tieferen Einblick in Microservice-Architekturen und Domain Driven Design vermitteln die beiden Trainings \u201eFlexible Architekturmodelle (FLEX)\u201c<\/a> und \u201eDomain Driven Design (DDD)\u201c<\/a>. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced\u00a0Level (CPSA-A \u00ae)<\/a> anstreben, erhalten Sie mit diesem perfekten Trainings-Doppelpack Credit Points in den Kompetenzbereichen Technik, Methodik und Kommunikation.<\/em><\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":" Axel Feix hat langj\u00e4hrige Projekterfahrung als Analyst und Softwarearchitekt. Er unterst\u00fctzt Kunden als Senior Consultant und Trainer bei der Einf\u00fchrung und Umsetzung von Software-Engineering, Requirements-Engineering, Softwarearchitektur-Management und Architekturdokumentation. Er interessiert sich f\u00fcr was fliegt, alles was man visualisieren und spielen kann, und was die Welt zusammenh\u00e4lt. Microservices und Domain Driven Design (DDD) z\u00e4hlen nach wie […]<\/p>\n","protected":false},"author":24783,"featured_media":24231,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[839,551,549,553],"tags":[],"class_list":["post-24212","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-plattform","category-kommunikativ","category-methodisch","category-projekte"],"_links":{"self":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/24212","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/users\/24783"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/comments?post=24212"}],"version-history":[{"count":10,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/24212\/revisions"}],"predecessor-version":[{"id":53842,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/24212\/revisions\/53842"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/media\/24231"}],"wp:attachment":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/media?parent=24212"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/categories?post=24212"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/tags?post=24212"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Bounded Context und Ubiquitous Language<\/h2>\n
Ein Bounded Context ist kein Microservice<\/h2>\n
Das richtige Werkzeug f\u00fcr den Einsatz von DDD und Microservices<\/h2>\n
Fazit<\/h2>\n
Sie m\u00f6chten mehr zu dem Thema erfahren?<\/span><\/h2>\n