Architecture

Marten, Polecat, and Wolverine on your domain.

I design one bounded context for a .NET team, on the database they already run. Marten stores the document in PostgreSQL. Polecat is that document model on SQL Server. Wolverine carries the messages, including the outbox.

Talk about the architecture

What the design covers

  • One bounded context

    The engagement is one context you already have, the one that hurts. I draw the boundary around the aggregate that is loaded and saved as a whole.

  • Marten or Polecat

    Marten keeps that document in PostgreSQL. Polecat keeps it on SQL Server. EF Core stays for the rows that are actually relational.

  • Wolverine

    Handlers, the outbox, and the broker you already run. The message and the state commit together.

  • What you leave with

    The boundary, the storage choice, the message topology, and one reference slice the team can continue. The rest of the system stays where it is.

The same decisions, written out: Marten as a document database, Marten event sourcing, CQRS in .NET with Wolverine, and the transactional outbox. When the question is EF Core or a document on the database you already run, that decision is EF Core, Marten, and Polecat.