Wie mit steigender Komplexität umgehen

Hallo, ich arbeite an einer plugin.dll bestehend aus einer Klasse, die mit Leben gefüllt werden muss.

Die Funktionalität, d.h. der Funktionsumfang, wird zunehmend komplexer und umfangreicher.

Auch die Notwendigkeit zusätzlicher Erweiterungen ist vorhanden.

Ich lagere das teilweise in Klassen aus, welche dann in der dll instantiiert werden.

Mein Ziel ist allerdings eine leicht zu wartende Software, welche möglichst nicht ineinander verschachtelt ist und leicht erweitert werden kann.

Nun habe ich gelesen, dass es verschiedene "Design Pattern" für alle möglichen Zwecke gibt.

Hättet Ihr einen Tipp, womit ich mich idealerweise mal beschäftigen sollte, um mein o.g. Ziel ggf. besser in den Griff zu bekommen ?

Architekturen und die Anwendung von Design Pattern sind leider vor allem ein Erfahrungsthema.
Was Du als komplex empfindest, finden andere als super simpel - oder umgekehrt. Komplexität hat auch überwiegend damit zutun, das Projekt und den Code zu kennen. Niemand hier im Forum kennt Deinen Code und weiß was Deine plugin.dll ist.

Es gibt verschiedene Bücher, die die wichtigsten Design Pattern erklären - aber es gibt sehr viele Pattern; und auf einen Anwendungsfall passen auch mehrere Pattern.
Das Must Have Book schlechthin ist Design Patterns. Elements of Reusable Object-Oriented Software. von Erich Gamma.

Daher kann man hier keine pauschale Antwort geben: Software wird schnell komplex, und da gibts kein generelles Gegenmittel dagegen, was im Prinzip auch gut so ist.

Auch ist die Wahrheit, dass es nicht "die perfekten Pattern" gibt. Quasi alle Pattern lösen ein gewisses Problem; bringen aber auch Nachteile mit sich.

Was 99% der .NET Devs nicht beherrschen, aber die absolute Grundlage jeder guten Architektur ist, ist der korrekte Umgang mit Namespaces und Projekten.
Hat man den Framework Design Guide nicht im Griff, hilft Dir auch das beste Buch nichts.
Framework design guidelines - Naming guidelines
Framework design guidelines - Names of Namespaces

und Feedback zu Dir, weil ich Deine anderen Themen kennen: es wirkt so, dass Du das ganze Thema .NET Fundamentals nicht durchgelesen hast und nicht anwendest.
Dir wurde bzgl. den Docs ja eh schon das Feedback gegeben, mal nachzulesen, was Du ja dankend ablehnend beantwortet hast. Ohne Lesen wirds aber schwer sowas zu lernen 😃
Konzepte lernt man leider nicht über Try-and-Error kennen.

Nimm Dir also die Zeit, und lern die Fundamentals.

Vereinfacht fügt man die wenig(er) veränderlichen Teile einer Software zusammen und lagert die stärker veränderlichen Teile geschickt aus. Wobei es aber auch auf den Ziel-Kontext ankommt, welche Teile welchem (feingranularen) Änderungs- oder Erweiterungsgrad unterliegen.

Schlagwörter wie "SOLID-Prinzipien" (*), "DDD", "Namensgebung", "TDD", "KISS", "Namespaces",...  dienen dem Menschen als Empfehlungen (nicht als Gesetz) um das (häufige) Ändern / Erweitern / Warten /..  der Software zu erleichtern (<- ab einer gewissen Komplexität dürfte aber selbst ein (grösseres) Spezialisten-Team damit ein Problem haben)

(*)das Auslagern in Klassen könnte langfristig gegen das I und D verstossen