From dce69bd4c60641ce08cec4e597595a2e40b535ba Mon Sep 17 00:00:00 2001 From: Anne Erdtsieck Date: Wed, 4 Jun 2025 10:31:24 +0700 Subject: [PATCH] Just some small clumpsy looking tutorial docs improvement --- docs/tutorials/evolve-to-event-sourcing.md | 2 -- docs/tutorials/index.md | 4 ---- docs/tutorials/modeling-documents.md | 14 -------------- docs/tutorials/wolverine-integration.md | 6 ------ 4 files changed, 26 deletions(-) diff --git a/docs/tutorials/evolve-to-event-sourcing.md b/docs/tutorials/evolve-to-event-sourcing.md index 46e6c0dbaf..d48e3fe7e4 100644 --- a/docs/tutorials/evolve-to-event-sourcing.md +++ b/docs/tutorials/evolve-to-event-sourcing.md @@ -20,8 +20,6 @@ For our delivery system, this means: - Natural modeling of workflows and temporal logic - Easier integration with external systems through event publishing ---- - ## Identifying Events (Event Modeling) The first step is to define our domain events. These events should represent meaningful transitions or actions in the freight shipping process. Based on our earlier description, we have a few key moments: diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md index 12108aff0a..7e404f1fbc 100644 --- a/docs/tutorials/index.md +++ b/docs/tutorials/index.md @@ -2,8 +2,6 @@ > This tutorial introduces you to Marten through a real-world use case: building a freight and delivery management system using documents and event sourcing. You'll learn not just how to use Marten, but also why and when to apply different features, and how to integrate them with Wolverine for a complete CQRS and messaging architecture. ---- - ## What You Will Learn - Why Marten's approach to Postgres as a document and event database is unique and powerful @@ -14,8 +12,6 @@ - How to reliably send notifications using the Wolverine outbox - How to scale with async projections and optimize performance ---- - ## Why Marten? The Power of Postgres + .NET Many document databases and event stores are built on top of document-oriented NoSQL engines like MongoDB, DynamoDB, or Cosmos DB. Marten takes a different path: it builds a document store and event sourcing system **on top of PostgreSQL**, a relational database. diff --git a/docs/tutorials/modeling-documents.md b/docs/tutorials/modeling-documents.md index 707564060a..67dd264484 100644 --- a/docs/tutorials/modeling-documents.md +++ b/docs/tutorials/modeling-documents.md @@ -2,8 +2,6 @@ In this chapter, we'll define the domain model for our freight and delivery system and store it in PostgreSQL using Marten as a document database. ---- - ## Learning Goals - Design C# document types (`Shipment`, `Driver`) @@ -11,8 +9,6 @@ In this chapter, we'll define the domain model for our freight and delivery syst - Query documents using LINQ - Understand Marten's identity and schema conventions ---- - ## Defining Documents We'll start by modeling two core entities in our domain: `Shipment` and `Driver`. @@ -41,8 +37,6 @@ public class Driver Once defined, Marten will automatically create tables like `mt_doc_shipment` and `mt_doc_driver` with a `jsonb` column to store the data. ---- - ## Storing Documents ```csharp @@ -70,8 +64,6 @@ await session.SaveChangesAsync(); Marten uses PostgreSQL's `INSERT ... ON CONFLICT DO UPDATE` under the hood to perform upserts. ---- - ## Querying Documents Use LINQ queries to fetch or filter data: @@ -96,8 +88,6 @@ var active = await querySession > You can also project into DTOs or anonymous types for performance if you don’t need the full document. ---- - ## Indexing Fields for Performance If you frequently query by certain fields, consider duplicating them as indexed columns: @@ -109,8 +99,6 @@ opts.Schema.For().Duplicate(x => x.AssignedDriverId); This improves query performance by creating indexes on those columns outside the JSON. ---- - ## Visual Recap ```mermaid @@ -120,8 +108,6 @@ flowchart TB B -->|Query: Destination = Chicago| D[LINQ Result] ``` ---- - ## Summary - Documents are plain C# classes with an `Id` property diff --git a/docs/tutorials/wolverine-integration.md b/docs/tutorials/wolverine-integration.md index ef9b33e6e7..944721eab1 100644 --- a/docs/tutorials/wolverine-integration.md +++ b/docs/tutorials/wolverine-integration.md @@ -7,8 +7,6 @@ This integration serves **two distinct purposes**: 1. Event-driven messaging and transactional command handling 2. Coordinated background projection processing in distributed environments ---- - ## Reliable Messaging with Aggregates When using event sourcing, emitting events from domain aggregates is common — and often, we want to trigger side effects (notifications, follow-up commands, integration events). With just Marten, you'd need to handle messaging yourself, risking lost messages in case of failure. @@ -43,8 +41,6 @@ Wolverine will: The outbox ensures **exactly-once** messaging. The inbox can guarantee that incoming messages are processed **only once**, even across retries. ---- - ### Distributed Projections in Multi-Node Environments If you run your freight system across multiple nodes (e.g. for horizontal scaling or redundancy), Marten’s async projection daemon needs coordination — to avoid multiple nodes processing the same projection. @@ -72,8 +68,6 @@ builder.Services.AddMarten(opts => This ensures that your projection daemon is managed by Wolverine’s distributed coordinator. ---- - ### Summary - **Messaging + Aggregates**: Wolverine makes it easy to process commands, generate events, and send follow-up messages, all with transactional guarantees.