Von einer Schulung zu Design Patterns würde ich auch abraten, da diese im Grunde nur eine Sammlung von Fallbeispielen sind. Hier würde ich empfehlen, dass ihr euch eine Liste der häufigsten Design Patterns raussucht und jeder dann jeweils ein Pattern bearbeitet und vorstellt. Idealerweise sogar praxisbezogen an eurer Anwendung mit anschließender Diskussion.
Wichtig zu Design Patterns ist aber folgendes: Der häufigste Fehler ist, dass diese falsch herum angewendet werden. Sprich: Jemand lernt programmieren, stellt fest, dass er nur mühselig Code schreiben kann, sucht nach Hilfe, entdeckt Design Patterns, findet diese hilfreich und stopft dann seinen Code mit so vielen Patterns wie möglich voll. Das mag eine schöne Übung sein - vor allem zur Horizonterweiterung, was man für Konstrukte mit Programmiersprachen bauen kann - erzeugt aber einen hoffnungslos über-komplexen Code.
Die Idee hinter Design Patterns ist, den "Mental Load" zu reduzieren. Also jemand schreibt Code und stellt dann fest, dass dieser Code einem Pattern entspricht. Daher benennt er diesen Code nach dem Pattern. Dies erlaubt dann einem anderen Entwickler sofort zu erkennen, was dieser Code macht und muss diesen nicht erst auf seine Funktion hin analysieren.
Wenn ich eine Schulung empfehlen soll, dann zum Thema DDD und CQRS.
Der häufigste Fehler in der Softwareentwicklung ist, mit dem Datenbankmodell anzufangen - vielleicht sogar weil dieses schon vorhanden ist - und daraus sein Klassen/Objektmodell abzuleiten. Vielleicht sind sogenannte Objekt-Relationale-Mapper bekannt. Hier ist die Richtung das entscheidende: Objekt --> Relational. Es gibt aus guten Grund keine Relational-Objekt-Mapper. Daher sollte man es auch vermeiden mit dem Datenbankmodell anzufangen.
DDD oder Domain Driven Design verfolgt diesen Ansatz. Die Idee ist, dass man die Anwendungsdomäne (auch Fach- oder Geschäftslogik) in Isolation, also ohne technische Abhängigkeiten zu verwendeten Datenbanken, GUI, Web oder sonstigen Frameworks, entwickelt und diese dann erst im Anschluss andockt.
Das erlaubt den Entwicklern sich auf die optimale Abbildung der Geschäftsregeln zu konzentrieren.
DDD ist natürlich ein großes Feld, aber schon die Grundlagen erleichtern die Entwicklung massiv. Dafür reicht es zu wissen, was die vier grundlegenden Typen von Objekten in der Anwendungsdomäne sind: Entities, Object-Values, Services und Repositories.
CQRS steht für Command Query Responsibility Segregation und hilft bei der Persistenz des Datenmodells und ist im Grunde ein "fancy" Name für "Es gibt zwei Datenmodelle: Eins zum Lesen (Query) und eins zum Schreiben (Command)". CQRS beerbt das klassische CRUD (Create Read Update Delete), bei dem es vier Methoden gibt, jeweils eine um einen Datensatz zu erstellen, zu lesen, zu ändern und zu löschen. Problematisch bei CRUD ist die Update-Methode. Übergibt man ein Objekt an diese Methode, weiß der implementierende Code nicht, was sich an dem Objekt geändert hat. CQRS hilft hier aus, indem man die Gründe für eine Änderung an einem Objekt als separate Methoden realisiert. Soll zum Beispiel bei einer Bestellung etwas geändert werden, gibt es nach CRUD nur eine updateOrder(order)-Methode. Diese weiß aber nicht, was sich geändert hat und ist daher schwer zu implementieren. Nach CQRS gibt es für jeden Änderungsgrund eine eigene Methode: persistDeliveryAddressChanged(orderNumber, deliveryAddress), persistOrderLineChanged(orderNumber, orderLine) etc. Die Implementierung der einzelnen Methoden ist dann trivial.
Eine konkrete Schulung kann ich leider nicht empfehlen, aber ich denke mit einer Grundlangenschulung zu DDD kann man nichts falsch machen. War diese gut, kann man darauf aufbauend tiefer in DDD einsteigen.