[et_pb_section fb_built=”1″ _builder_version=”3.22″ custom_padding=”0px||0px|||”][et_pb_row _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” custom_margin=”28px|auto||auto||” custom_padding=”0px|0px|0px|0px||”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text _builder_version=”4.6.1″]<\/p>\n
W\u00e4hrend die Skyline unserer Softwarewelt nach wie vor von Monolithen gepr\u00e4gt ist, hat sich der Trend zu flexiblen Architekturmodellen mit Microservices, Continuous Deployment, DevOps und hohen Automatisierungsgraden auf m\u00f6glichst allen Ebenen inzwischen durchgesetzt. Und in der Tat: kompaktere, weitestgehend autarke Softwaremodule mit eigenen spezialisierten Teams bieten\u00a0eine Menge Vorteile – von der Konzeption \u00fcber Entwicklung und Testen bis in die Wartung. Verbesserte Stabilit\u00e4t, adaptive Reaktion auf ver\u00e4nderliche Anforderungen, Effizienz- und Kostenvorteile in der Weiterentwicklung sind Argumente, bei denen jedes Entscheiderherz h\u00f6her schlagen sollte.<\/p>\n
Aus architektonischer Sicht ist eine flexible Sortwarearchitektur allerdings leichter gesagt, als getan. Welche Methodik ist f\u00fcr mein Projekt die richtige? Anhand welcher Kriterien lassen sich Module zielf\u00fchrend abgrenzen? Wie kann ich von Anfang an vermeiden, dass sich bei zus\u00e4tzlichen oder sich ver\u00e4ndernden Anforderungen mit der Zeit der ber\u00fchmt-ber\u00fcchtigte\u00a0Big Ball of Mud bildet?<\/p>\n
[\/et_pb_text][et_pb_text _builder_version=”4.6.5″ text_font=”||||||||” ul_line_height=”1.5em” header_4_font=”|600|||||||” header_4_text_color=”#003f86″ background_color=”#f3f3f3″ custom_margin=”60px||60px||true|false” custom_padding=”35px|25px|15px|25px|false|true” hover_enabled=”0″ custom_css_main_element=”margin-top: 40px;||padding:20px;” border_width_all=”2px” border_color_all=”#86cbed” sticky_enabled=”0″]<\/p>\n
[\/et_pb_text][et_pb_text _builder_version=”4.6.5″ _module_preset=”default” link_font=”||||||||” link_text_color=”#003f86″ custom_padding=”||0px|||” hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n
F\u00fcr viele Softwarearchitekten ist Domain Driven Design (DDD) die Antwort auf diese und andere g\u00e4ngige Fragestellungen im Vorfeld einer flexiblen Architektur. DDD setzt konsequent auf die Fachlichkeit, und die liegt im Business des Unternehmens begr\u00fcndet, nicht im technischen Jargon des Entwicklerteams. Aus dem Business heraus lassen sich bereits in fr\u00fchen Phasen des strategischen Designs inhaltliche und funktionale Einheiten als Bounded Contexts\u00a0separieren. Aber auch im taktischen Design k\u00f6nnen sich sinnvolle Modularisierungsoptionen ergeben. So bildet die Fachlichkeit letztendlich die Basis f\u00fcr die Abgrenzung der Microservices und die Herausbildung dedizierter Teams.<\/p>\n
Architekten, die ihr Handwerk in diese Richtung entwickeln m\u00f6chten, finden in den iSAQB-akkreditierten Trainings\u00a0Flexible Architektur\u00admodelle, Microservices & Self-Contained Systems (FLEX<\/a>)<\/a> und Domain Driven Design (DDD)<\/a> ein starkes Doppelpack, in denen alle relevanten Grundlagen anschaulich und praxisnah vermittelt werden. In unserer ITech Academy z\u00e4hlt die Kombination von FLEX und DDD bereits seit \u00fcber zwei Jahr zu den am st\u00e4rksten nachgefragten, oft und gerne erg\u00e4nzt durch das Modul\u00a0Agile Softwarearchitektur (AGILA)<\/a>.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":" W\u00e4hrend die Skyline unserer Softwarewelt nach wie vor von Monolithen gepr\u00e4gt ist, hat sich der Trend zu flexiblen Architekturmodellen mit Microservices, Continuous Deployment, DevOps und hohen Automatisierungsgraden auf m\u00f6glichst allen Ebenen inzwischen durchgesetzt. Und in der Tat: kompaktere, weitestgehend autarke Softwaremodule mit eigenen spezialisierten Teams bieten\u00a0eine Menge Vorteile – von der Konzeption \u00fcber Entwicklung und […]<\/p>\n","protected":false},"author":1,"featured_media":18962,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"","_et_gb_content_width":"845","footnotes":""},"categories":[549,833,547,557],"tags":[],"class_list":["post-4215","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-methodisch","category-softwarearchitektur","category-technisch","category-trainings-und-workshops"],"_links":{"self":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/4215","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\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/comments?post=4215"}],"version-history":[{"count":10,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/4215\/revisions"}],"predecessor-version":[{"id":53850,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/4215\/revisions\/53850"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/media\/18962"}],"wp:attachment":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/media?parent=4215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/categories?post=4215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/tags?post=4215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}