Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 0 additions & 2 deletions docs/tutorials/evolve-to-event-sourcing.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down
4 changes: 0 additions & 4 deletions docs/tutorials/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.
Expand Down
14 changes: 0 additions & 14 deletions docs/tutorials/modeling-documents.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,17 +2,13 @@

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`)
- Store documents using Marten
- 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`.
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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:
Expand All @@ -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:
Expand All @@ -109,8 +99,6 @@ opts.Schema.For<Shipment>().Duplicate(x => x.AssignedDriverId);

This improves query performance by creating indexes on those columns outside the JSON.

---

## Visual Recap

```mermaid
Expand All @@ -120,8 +108,6 @@ flowchart TB
B -->|Query: Destination = Chicago| D[LINQ Result]
```

---

## Summary

- Documents are plain C# classes with an `Id` property
Expand Down
6 changes: 0 additions & 6 deletions docs/tutorials/wolverine-integration.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand Down
Loading