Bitte wählen Sie die Bereiche, die Sie exportieren möchten:
Alle C# SchulungenSchulung Clean Architecture und Domain-Driven Design mit C#
Schulung Clean Architecture und Domain-Driven Design mit C#
Entities, Value Objects, Aggregates und Use Cases
4 Tage / S6870
Neues SeminarSchulungsformen
Offene Schulung
- 4 Tage
- 5 gesicherte Termine
- Köln / Online
- 2.660,00 p. P. zzgl. MwSt.
- Dritter Mitarbeitende kostenfrei
- Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
Präsenz Online
Inhouse-/Firmenschulung
- 4 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- 4 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Beschreibung
Die meisten .NET-Applikationen beginnen als CRUD: Controller ruft Service, Service ruft Repository, Repository ruft Entity Framework. Das funktioniert für einfache Domänen. Aber wenn die Geschäftslogik wächst - Bestellprozesse mit Rabatten, Stornierungen und Teillieferungen, Versicherungspolicen mit Klauseln, Deckungssummen und Schadensabwicklung, Personalmanagement mit Genehmigungsketten, Urlaubsansprüchen und Gehaltsberechnungen - dann wird CRUD zum Albtraum. Die Geschäftslogik verteilt sich über Controller, Services, Repositories und sogar Stored Procedures. Niemand weiß mehr, wo die Regel „Bestellungen über 10.000 € brauchen Genehmigung der Geschäftsführung" implementiert ist.
Domain-Driven Design löst das Modellierungsproblem: Die Fachsprache der Domäne (Ubiquitous Language) wird 1:1 in Code übersetzt. Geschäftsregeln leben in Entities und Value Objects, nicht in Services. Aggregate-Grenzen definieren Konsistenzgrenzen. Domain Events entkoppeln Seiteneffekte. Bounded Contexts verhindern, dass ein monolithisches Modell entsteht.
Clean Architecture löst das Strukturproblem: Die Dependency Rule stellt sicher, dass die Domäne von nichts abhängt - nicht von der Datenbank, nicht vom Web-Framework, nicht von externen Services. Use Cases orchestrieren die Domänenlogik. Interface Adapters übersetzen zwischen Domäne und Außenwelt. Die Architektur ist testbar, austauschbar und langlebig.
Dieses viertägige Seminar verbindet beide Ansätze in C# - nicht als Theorie, sondern als durchgängiges Implementierungsprojekt: eine reale Geschäftsdomäne, modelliert mit DDD, strukturiert mit Clean Architecture, implementiert mit ASP.NET Core, EF Core und MediatR.
Domain-Driven Design löst das Modellierungsproblem: Die Fachsprache der Domäne (Ubiquitous Language) wird 1:1 in Code übersetzt. Geschäftsregeln leben in Entities und Value Objects, nicht in Services. Aggregate-Grenzen definieren Konsistenzgrenzen. Domain Events entkoppeln Seiteneffekte. Bounded Contexts verhindern, dass ein monolithisches Modell entsteht.
Clean Architecture löst das Strukturproblem: Die Dependency Rule stellt sicher, dass die Domäne von nichts abhängt - nicht von der Datenbank, nicht vom Web-Framework, nicht von externen Services. Use Cases orchestrieren die Domänenlogik. Interface Adapters übersetzen zwischen Domäne und Außenwelt. Die Architektur ist testbar, austauschbar und langlebig.
Dieses viertägige Seminar verbindet beide Ansätze in C# - nicht als Theorie, sondern als durchgängiges Implementierungsprojekt: eine reale Geschäftsdomäne, modelliert mit DDD, strukturiert mit Clean Architecture, implementiert mit ASP.NET Core, EF Core und MediatR.
Vertiefen Sie Ihr Wissen mit einem weiteren C# Training aus unserem Angebot.
Schulungsziel
Jede teilnehmende Person verlässt das Seminar mit einer vollständigen DDD/Clean-Architecture-Referenzapplikation in C# (Domänenmodell, Use Cases, Infrastructure, Tests), dem Verständnis von strategischem DDD (Bounded Contexts, Context Maps, Ubiquitous Language), der Fähigkeit, taktisches DDD in C# zu implementieren (Entities, Value Objects, Aggregates, Domain Events, Repositories), CQRS und MediatR als Use-Case-Architektur , einer getesteten Architektur (Unit, Integration, Architecture Tests) und 5 Architecture Decision Records als Dokumentationsvorlage.
Details
Inhalt
Tag 1: Strategisches DDD - Die Domäne verstehen
1. Warum DDD und Clean Architecture?
4. Rich Domain Model: Geschäftslogik in Entities
7. Clean Architecture: Schichten und Projektstruktur
10. Event Sourcing, Outbox Pattern und Vertical Slices
Phase 1 - Architektur-Review (20 Min):
1. Warum DDD und Clean Architecture?
- Ziele und Erwartungen der Teilnehmenden
- Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
- Das CRUD-Problem: Anemic Domain Model (Entities ohne Logik, Services mit aller Logik), Big Ball of Mud (keine erkennbare Architektur), Feature Envy (Controller kennt Geschäftsregeln). Symptome: jede Änderung hat unvorhergesehene Seiteneffekte, Tests sind unmöglich, neue Entwickler brauchen Monate Einarbeitung.
- Wann DDD lohnt und wann nicht: DDD für komplexe Geschäftsdomänen (Versicherung, Logistik, Finance, Healthcare). Nicht für einfache CRUD-Applikationen (Blog, Todo-App, Datenverwaltung) - Overengineering vermeiden.
- Clean Architecture im Überblick: Concentric Circles (Enterprise Business Rules -> Application Business Rules -> Interface Adapters -> Frameworks & Drivers). Die Dependency Rule: Abhängigkeiten zeigen immer nach innen.
- Abgrenzung: Clean Architecture vs. Hexagonal Architecture (Ports & Adapters) vs. Onion Architecture - drei Namen für dasselbe Prinzip. Vertical Slice Architecture als pragmatische Alternative.
- Praxis-Übung: Bestehende CRUD-Applikation analysieren - wo steckt die Geschäftslogik? Im Controller? Im Service? Im Repository? Architektur-Smell-Katalog durchgehen.
- Ubiquitous Language: Fachsprache der Domäne wird 1:1 in Code übersetzt. Nicht „OrderItem" wenn der Fachbereich „Position" sagt. Nicht „User" wenn der Fachbereich „Versicherungsnehmer" meint. Glossar als lebendes Dokument, gepflegt von Entwicklern UND Fachbereich.
- Event Storming als Discovery-Methode: Domain Events auf Sticky Notes (orange), Commands (blau), Aggregates (gelb), Bounded Contexts (Rahmen). In 2-4 Stunden die Domäne visualisieren - schneller als jedes Pflichtenheft.
- Bounded Contexts: Jeder Kontext hat sein eigenes Modell. „Kunde" im Vertrieb (Name, Adresse, Umsatz) ≠ „Kunde" im Support (Tickethistorie, SLA, Kontaktpräferenzen) ≠ „Kunde" in der Buchhaltung (Debitorennummer, Zahlungsziel, Mahnstatus). Jeder Kontext darf dasselbe Wort anders definieren.
- Context Mapping: Wie kommunizieren Bounded Contexts? Shared Kernel, Customer-Supplier, Conformist, Anti-Corruption Layer, Open Host Service, Published Language. Entscheidungsmatrix: Wann welches Pattern?
- Vom Bounded Context zum Microservice: Ein Bounded Context = ein potenzieller Microservice. Nicht zwingend - aber die natürliche Grenze. Brücke zum geplanten Seminar „Microservices mit .NET" (4T).
- Praxis-Übung: Event Storming für die Seminar-Domäne (E-Commerce oder Versicherung): Domain Events identifizieren, Commands ableiten, Aggregates gruppieren, 3 Bounded Contexts definieren. Context Map zeichnen.
- Entity vs. Value Object: Entities haben Identität (Bestellung #4711 bleibt dieselbe Bestellung, auch wenn sich der Status ändert). Value Objects haben keine Identität (Adresse, Geldbetrag, Datumsbereich - Gleichheit über Werte, nicht über ID). C#-Implementierung: Entity mit Id-Property, Value Object als record oder mit Equals/GetHashCode-Override.
- Value Objects als Geschäftstypen: Nicht decimal für Geld, sondern Money(decimal Amount, Currency Currency). Nicht string für E-Mail, sondern EmailAddress mit Validierung im Konstruktor. Value Objects schützen Invarianten und machen den Code ausdrucksstärker.
- Aggregates und Aggregate Roots: Ein Aggregate ist eine Konsistenzgrenze - alle Änderungen innerhalb eines Aggregates sind atomar. Der Aggregate Root ist der einzige Zugriffspunkt von außen. Beispiel: Order (Root) -> OrderLine -> Money. Niemand greift direkt auf OrderLine zu - nur über Order.
- Aggregate-Design-Regeln: Aggregate klein halten (nicht die gesamte Domäne in ein Aggregate), Referenzen zwischen Aggregates nur über ID (nicht über Objektreferenz), Konsistenz nur innerhalb eines Aggregates garantiert (zwischen Aggregates: eventual consistency).
- Praxis-Übung: Domänenmodell für die Seminar-Domäne implementieren: 2 Aggregates (z.B. Order mit OrderLine und Money, Customer mit Address und EmailAddress). Value Objects als record, Entities mit Id, Geschäftsregeln im Aggregate Root (z.B. „Bestellung darf max. 50 Positionen haben", „Mindestbestellwert 10 €").
4. Rich Domain Model: Geschäftslogik in Entities
- Anemic vs. Rich Domain Model: Anemic = Entities sind nur Datencontainer, Services enthalten die Logik. Rich = Entities enthalten ihre eigene Logik. Beispiel anemic: orderService.AddItem(order, product, quantity). Beispiel rich: order.AddItem(product, quantity) - die Bestellung weiß selbst, wie man eine Position hinzufügt, welche Rabatte gelten, wann das Maximum erreicht ist.
- Invarianten schützen: Konstruktoren, die nur gültige Objekte erzeugen. Private Setter. Methoden statt Property-Zuweisungen. Beispiel: order.Cancel(reason) statt order.Status = OrderStatus.Cancelled - die Methode prüft, ob Stornierung erlaubt ist.
- Factory Methods: Statische Methoden für komplexe Objekt-Erzeugung. Order.Create(customer, items) statt new Order() + separate Initialisierung.
- Domain Exceptions: Fachliche Ausnahmen (z.B. InsufficientStockException, OrderAlreadyCancelledException) statt generische Exceptions. Klar, sprechend, teil der Ubiquitous Language.
- Praxis-Übung: Das Domänenmodell aus Topic 3 anreichern: Methoden Order.AddItem(), Order.RemoveItem(), Order.Cancel(), Order.Confirm() mit Geschäftsregeln implementieren. Invarianten durch Tests absichern (Unit Tests mit xUnit/NUnit).
- Was sind Domain Events? Fachliche Ereignisse, die innerhalb der Domäne auftreten: OrderPlaced, PaymentReceived, OrderShipped, CustomerRegistered. Vergangenheitsform (etwas IST passiert), immutable, tragen alle relevanten Daten.
- Warum Domain Events? Entkopplung von Seiteneffekten: Wenn eine Bestellung aufgegeben wird, muss eine E-Mail gesendet, der Lagerbestand reduziert und ein Rechnungsentwurf erstellt werden. Ohne Events: alles in Order.Place(). Mit Events: Order.Place() -> OrderPlacedEvent -> separate Handler für E-Mail, Lager, Rechnung.
- Domain Events in C# mit MediatR: INotification als Event-Interface, INotificationHandler<T> als Handler. In-Process-Events (synchron oder asynchron im selben Prozess). Für Cross-Service-Events: Outbox Pattern + RabbitMQ/Azure Service Bus.
- Raising Events: Entities sammeln Events in einer Collection (_domainEvents), die nach dem Speichern dispatched werden (EF Core SaveChanges Override oder MediatR Pipeline).
- Praxis-Übung: Domain Events implementieren: OrderPlacedEvent definieren, Handler für (1) Bestätigungs-E-Mail, (2) Lagerbestandsreduktion, (3) Audit-Log. Event-Dispatching über MediatR nach SaveChanges.
- Repository Pattern: Abstraktion über den Datenzugriff - die Domäne kennt kein Entity Framework, kein SQL, keine Datenbank. IOrderRepository mit GetById(), Add(), Update(). Implementierung in der Infrastruktur-Schicht mit EF Core.
- Repository vs. DbContext direkt: Wann lohnt sich die Abstraktion? Pro: Testbarkeit, Austauschbarkeit, Domänen-Reinheit. Contra: zusätzliche Indirektion, Leaky Abstractions bei komplexen Queries. Pragmatischer Mittelweg: Repository für Aggregates, DbContext für Read-Queries (CQRS).
- Specification Pattern: Wiederverwendbare Query-Logik in eigenen Klassen statt in Repositories. ActiveOrdersSpec, HighValueOrdersSpec - kombinierbar, testbar.
- Domain Services: Logik, die nicht natürlich zu einer einzelnen Entity gehört. Beispiel: PricingService.CalculateDiscount(order, customer) - braucht Daten aus zwei Aggregates. Domain Services sind stateless, operieren auf Entities und Value Objects.
- Praxis-Übung: IOrderRepository definieren, EF-Core-Implementierung schreiben (mit DbContext). Specification Pattern für „Offene Bestellungen über 1.000 €" implementieren. Domain Service PricingService mit Rabattlogik (Mengenrabatt, Kundenklassen-Rabatt) implementieren und testen.
7. Clean Architecture: Schichten und Projektstruktur
- Die vier Schichten: Domain (Entities, Value Objects, Aggregates, Domain Events, Repository-Interfaces - keine Abhängigkeiten), Application (Use Cases, DTOs, Interfaces für externe Services - hängt nur von Domain ab), Infrastructure (EF Core, Repositories, E-Mail-Service, externe APIs - implementiert Interfaces aus Application/Domain), Presentation (ASP.NET Core Controller/Minimal APIs, ViewModels - ruft Application auf).
- Dependency Rule: Äußere Schichten hängen von inneren ab, nie umgekehrt. Domain kennt kein EF Core, kein ASP.NET, kein MediatR. Application kennt kein EF Core. Infrastructure implementiert Interfaces, die in Application/Domain definiert sind.
- .NET-Projektstruktur: MyApp.Domain (Class Library, zero Dependencies), MyApp.Application (Class Library, referenziert Domain + MediatR), MyApp.Infrastructure (Class Library, referenziert Application + EF Core + externe SDKs), MyApp.Api (ASP.NET Core, referenziert Application + Infrastructure, DI-Registrierung).
- Dependency Injection als Architektur-Enabler: Interfaces in Domain/Application, Implementierungen in Infrastructure, Registrierung in Program.cs. Microsoft.Extensions.DependencyInjection reicht - kein Drittanbieter-Container nötig.
- Praxis-Übung: Solution-Struktur anlegen (4 Projekte), Projekt-Referenzen korrekt setzen (Dependency Rule prüfen: Domain referenziert NICHTS, Application referenziert nur Domain, Infrastructure referenziert Application, Api referenziert alle). Domänenmodell und Repositories aus Tag 2 in die richtige Schicht verschieben.
- Use Cases als Application-Schicht-Konzept: Ein Use Case = eine fachliche Operation (z.B. PlaceOrder, CancelOrder, GetOrderDetails). Nicht CRUD (Create, Read, Update, Delete), sondern fachliche Verben.
- CQRS: Command Query Responsibility Segregation. Commands ändern den Zustand (Write), Queries lesen den Zustand (Read). Separates Modell für Schreiben (Domain Model, Aggregates, Repositories) und Lesen (Read Models, Projections, Dapper/Raw SQL).
- MediatR als Use-Case-Dispatcher: IRequest<T> für Commands und Queries, IRequestHandler<TRequest, TResponse> für Handler. Controller ruft mediator.Send(new PlaceOrderCommand(...)) auf -> Handler orchestriert Domänenlogik.
- Pipeline Behaviors: Cross-Cutting Concerns als MediatR-Pipeline: Validation (FluentValidation), Logging, Performance Monitoring, Transaction Management. Einmal konfiguriert, für alle Use Cases aktiv.
- FluentValidation: Command-Validierung vor dem Handler - PlaceOrderCommandValidator prüft Eingabedaten, bevor die Domäne berührt wird. Validation Errors als strukturierte Fehlermeldungen zurück an den Client.
- Praxis-Übung: 4 Use Cases implementieren: PlaceOrderCommand (Command + Handler + Validator), CancelOrderCommand, GetOrderByIdQuery (Query + Handler mit Read Model), GetActiveOrdersQuery. MediatR Pipeline Behavior für Logging und Validation einrichten.
- EF Core mit DDD: Aggregate als DbSet, Value Objects als Owned Types oder Value Conversions, Private Constructors mit EF-Core-Configuration (HasNoKey, HasConversion). Shadow Properties für Infrastruktur-Felder (CreatedAt, ModifiedAt). Domain Events dispatchen in SaveChanges Override.
- Repository-Implementierung: Generic Repository vs. Aggregate-spezifische Repositories. Include-Strategien für Aggregates (Eager Loading der gesamten Aggregate-Grenze).
- Anti-Corruption Layer: Externe APIs (Payment Gateway, ERP, CRM) werden durch Interfaces in der Application-Schicht abstrahiert und in der Infrastructure-Schicht implementiert. Die Domäne kennt kein externes System - nur das Interface.
- Mapping: Domain Entities -> DTOs -> API-Response. AutoMapper vs. Mapster vs. manuelle Mapping-Methoden. Empfehlung: manuelle Mappings für einfache Fälle, Mapster für komplexe (Performance-Vorteil gegenüber AutoMapper).
- Praxis-Übung: EF-Core-Konfiguration für die Domäne schreiben: OrderConfiguration mit Owned Types für Money und Address, Value Conversion für EmailAddress. Migration erstellen und ausführen. Repository-Implementierung vervollständigen. Anti-Corruption-Layer für einen fiktiven Payment-Service implementieren.
10. Event Sourcing, Outbox Pattern und Vertical Slices
- Event Sourcing Kurzüberblick: Statt aktuellen Zustand zu speichern, alle Events speichern und Zustand daraus ableiten. Wann sinnvoll (Audit, Zeitreisen, komplexe Domänen), wann Overkill (einfache CRUD). Zusammenspiel mit CQRS: Events schreiben, Read Models projizieren. Referenz auf Marten (PostgreSQL Event Store) und EventStoreDB.
- Outbox Pattern: Domain Events zuverlässig an Message Broker senden - Transaction-Outbox: Events in derselbe DB-Transaktion wie die Domänenänderung speichern, Background Worker liest Events und publisht an RabbitMQ/Azure Service Bus. Garantiert: kein Event geht verloren, auch bei Crash.
- Vertical Slice Architecture als Alternative: Statt horizontale Schichten (Domain, Application, Infrastructure) -> vertikale Feature-Ordner. Jeder Slice enthält Command, Handler, Validator, Repository, Endpoint in einem Ordner. Pro: weniger Indirektion, Feature-orientiert. Contra: weniger wiederverwendbar. Empfehlung: Clean Architecture für Domain Model, Vertical Slices für Application Layer.
- Pragmatismus: Nicht jeder Bounded Context braucht DDD. Core Domain (hohe Komplexität, Wettbewerbsvorteil) -> volles DDD. Supporting Domain (nötig, aber nicht komplex) -> einfacheres Modell. Generic Domain (Standardproblem) -> Produkt kaufen (z.B. Auth mit Identity Framework).
- Praxis-Übung: Outbox-Pattern implementieren: Domain Event in Outbox-Tabelle speichern (in gleicher Transaktion wie Aggregate), Background Service liest und publisht an In-Memory-Message-Bus.
- Testpyramide für DDD: Unit Tests (Domänenlogik - Aggregate-Methoden, Value Objects, Domain Services), Integration Tests (Use Cases - MediatR Handler mit echtem DbContext oder In-Memory-DB), End-to-End Tests (API-Endpoints mit WebApplicationFactory).
- Domänen-Unit-Tests: Aggregates testen (Arrange -> Act -> Assert auf Zustand und Events). Value Objects testen (Equality, Validation). Domain Services testen (mit gemockten Repositories). Kein EF Core, kein HTTP, kein MediatR - pure Logik.
- Use-Case-Integration-Tests: MediatR Handler testen mit echtem DbContext (In-Memory oder SQLite). Command senden -> Datenbank-Zustand prüfen. Query senden -> Response prüfen. Aspire.Testing als Alternative für vollständige End-to-End-Tests (Brücke zum Seminar „.NET Aspire", NEU, 2T).
- Architecture Tests mit NetArchTest: Automatisch prüfen, dass die Dependency Rule eingehalten wird. Types.InAssembly(domainAssembly).ShouldNot().HaveDependencyOn("Infrastructure"). Als CI-Check: Architektur-Verletzung bricht den Build.
- Praxis-Übung: 10 Tests schreiben: (1-3) Unit Tests für Aggregate (AddItem, Cancel, Invarianten-Verletzung), (4-5) Unit Tests für Value Objects (Money Equality, EmailAddress Validation), (6-7) Integration Tests für Use Cases (PlaceOrder, GetOrderById), (8) Architecture Test mit NetArchTest (Dependency Rule), (9-10) End-to-End Test (API-Endpoint mit WebApplicationFactory).
Phase 1 - Architektur-Review (20 Min):
- Die im Seminar gebaute Applikation als Ganzes betrachten: Solution-Struktur, Domänenmodell, Use Cases, Infrastructure, Tests.
- Architektur-Entscheidungen dokumentieren: ADR (Architecture Decision Records) für die 5 wichtigsten Entscheidungen (warum CQRS, warum MediatR, warum Owned Types, warum Outbox, warum Repository Pattern).
- Geschäftsdomäne aus der eigenen Organisation wählen (oder vorgegebenes Szenario).
- Bounded Contexts identifizieren, Aggregate-Grenzen definieren, 2 Use Cases als MediatR-Handler skizzieren, Projektstruktur aufsetzen.
- Domänenmodell vorstellen. Feedback: Sind die Aggregate-Grenzen richtig? Sind die Value Objects wirklich Value Objects? Ist die Dependency Rule eingehalten?
- Stresstest: „Eine neue Geschäftsregel erfordert Daten aus zwei Aggregates - wie löst du das?" „Ein neuer Kanal (Mobile App) soll dieselbe Logik nutzen - was musst du ändern?"
Zielgruppe & Vorkenntnisse
- Senior-C#-Entwickler: Die von CRUD-Applikationen zu fachlich getriebenen Architekturen übergehen wollen.
- Solution Architects und Tech Leads: Die Architekturentscheidungen für .NET-Enterprise-Applikationen treffen und durchsetzen.
- Backend-Entwickler in Microservices-Projekten: Die Service-Schnitte, Bounded Contexts und Aggregate-Grenzen fachlich begründen.
- Entwickler, die Legacy-Code modernisieren: Die gewachsene Monolithen in wartbare Strukturen überführen - ohne Big-Bang-Rewrite.
Abgrenzung: Dieses Seminar behandelt Architekturmuster und fachliche Modellierung mit C# - nicht Entwurfsmuster im klassischen GoF-Sinne (dafür: S721, 3T), nicht Microservices-Infrastruktur (dafür: „Microservices mit .NET" geplant, 4T), nicht ASP.NET-Grundlagen (dafür: S5063, 3T), nicht allgemeines Refactoring (dafür: S738, 3T).
Ihre Schulung
In Präsenz | Online |
|---|---|
| Lernmethode | |
Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC. | Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent. |
| Unterlagen | |
Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. | Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. |
| Arbeitsmaterialien | |
DIN A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its | |
| Teilnahmezertifikat | |
Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF. | |
Organisation
In Präsenz | Online | |
|---|---|---|
| Teilnehmendenzahl | ||
min. 1, max. 8 Personen | ||
| Garantierte Durchführung | ||
Ab 1 Teilnehmenden* | ||
| Schulungszeiten | ||
| ||
| Ort der Schulung | ||
 GFU SchulungszentrumAm Grauen Stein 27 51105 Köln-Deutz oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden. Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen. | ||
| Räumlichkeiten | ||
Helle und modern ausgestattete Räume mit perfekter Infrastruktur | Bequem aus dem Homeoffice von überall | |
| Preisvorteil | ||
Dritter Mitarbeitende nimmt kostenfrei teil. Eventuell anfallende Prüfungskosten für den dritten Teilnehmenden werden zusätzlich berechnet. Hinweis: Um den Erfolg der Schulung zu gewährleisten, sollte auch der dritte Teilnehmende die erwarteten Vorkenntnisse mitbringen. | ||
| KOMPASS — Förderung für Solo-Selbstständige | ||
Solo-Selbstständige können für dieses Seminar eine Förderung via KOMPASS beantragen. | ||
| All-Inclusive | ||
Gebäck, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch | Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu. | |
| Barrierefreiheit | ||
Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei | - | |
Buchen ohne Risiko
| Rechnungsstellung |
Erst nach dem erfolgreichen Seminar. Keine Vorkasse. |
| Stornierung |
Kostenfrei bis zum Vortag des Seminars |
| Vormerken statt buchen |
Sichern Sie sich unverbindlich Ihren Seminarplatz schon vor der Buchung - auch wenn Sie selbst nicht berechtigt sind zu buchen |
Kostenfreie Services
In Präsenz | Online |
|---|---|
|
|
Buchungsmöglichkeiten
Online oder in Präsenz teilnehmen
Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.
Gesicherte offene Termine
| Termin | Ort | Preis | ||
|---|---|---|---|---|
| 03.08.-06.08.2026 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
| 05.10.-08.10.2026 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
| 07.12.-10.12.2026 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
| 2027 | ||||
| 19.04.-22.04.2027 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
| 21.06.-24.06.2027 Plätze vorhanden Köln / Online 2.660,00 | Köln / Online | 2.660,00 | Buchen Vormerken | |
Inhouse-/Firmenschulung
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Nachbetreuung
Unterstützung nach der Schulung durch
individuelle Nachbetreuung
FAQ für Offene Schulungen
Welche Schulungsform ist ideal für mich?
- Alle folgenden Schulungsformen können auch Online als Virtual Classroom durchgeführt werden.
- Eine Offene Schulung findet zu einem festgelegten Zeitpunkt im voll ausgestatteten Schulungszentrum oder Online/Remote statt. Sie treffen auf Teilnehmende anderer Unternehmen und profitieren vom direkten Wissensaustausch.
- Eine Inhouse-/Firmen-Schulung geht auf die individuellen Bedürfnisse Ihres Unternehmens ein. Sie erhalten eine kostenfreie Beratung von Ihrem Seminarleiter und können Inhalte und Dauer auf Ihren Schulungsbedarf anpassen. Inhouse-Schulungen können Europaweit durchgeführt werden.
- Bei einer Individual-Schulung erhalten Sie eine 1-zu-1 Betreuung und bestimmen Inhalt, Zeit und Lerntempo. Der Dozent passt sich Ihren Wünschen und Bedürfnissen an.
Wie kann ich an einer Online Schulung teilnehmen?
Sie können unsere Schulungen auch als Remote Schulung im Virtual Classroom anfragen.
In drei Schritten zum Online Seminar im Virtual Classroom:
- Seminar auswählen und auf "Buchen" klicken
- Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
- Formular ausfüllen und über den Button "Jetzt buchen" absenden.
Unser Kundenservice meldet sich bei Ihnen mit der Buchungsbestätigung.
Was ist ein Virtual Classroom?
Unsere Online Schulungen finden im Virtual Classroom statt. Ein Virtual Classroom bündelt mehrere Werkzeuge, wie Audio-Konferenz, Text-Chat, Interaktives Whiteboard, oder Application Sharing.
Vorteile von Virtual Classroom:
- Sie erhalten 1 zu 1 die gleiche Lernumgebung, die Sie auch vor Ort bei uns vorfinden
- Die technische Vorbereitung wird von den GFU-Technikern vorgenommen
- Sie erhalten remote Zugriff auf Ihren persönlichen Schulungs-PC im GFU-Seminarraum
- Die Virtual Classroom Lösung lässt sich auch im Browser betreiben
- Die GFU-Technik leistet wie gewohnt Soforthilfe bei Problemen
- Die Schulungsunterlagen bekommen Sie via DHL zugeschickt
- Sie sparen Reisekosten und Zeit
Welche gesicherten Termine gibt es?
- 03. Aug. - 06. Aug. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 05. Okt. - 08. Okt. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 07. Dez. - 10. Dez. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 19. Apr. - 22. Apr. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 21. Jun. - 24. Jun. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- Auch als Inhouse-Schulung, bundesweit mit Termin nach Wunsch und individuellen Inhalten
- Buchen ohne Risiko! Kostenfreie Stornierung bis zum Vortag des Seminars
Das GFU-Sorglos-Paket
Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!
Shuttle-Service
Machen Sie sich keinen Kopf um die Anreise! Unser Shuttle fährt Sie. Oder Sie parken einfach auf einem extra für Sie reservierten Parkplatz.
Hotelreservierung
Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!
Kostenfreies Storno
Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.
Technik-Support
Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.