Nobody writes 20,000 lines of code alone. Here's how we'll build it together.

Hey Mailwal!

7 days left to join The Domain Engineer.
I already know what you're thinking: "That's plenty of time."
I used to think the same. Then I missed a couple of things that didn't come back.

Learn more about The Domain Engineer

Many will open this email, nod, and tell themselves they'll sign up next week.
Then next week gets busy. The next cohort is half a year away, at a higher price.
Don't be one of those people who meant to join and ran out of time.

There is no other training where you build a 20,000-line Go project with this kind of hands-on depth.
If you decide to skip this round, there's no "I'll just buy the other one" option.

Most people learn techniques like DDD from conference talks and blog posts.
Then they try to apply them and it turns into a disaster, because theory skips the messy parts.
That's why we built The Domain Engineer as a hands-on project, not a video course.

Let me show you what you'll actually build.

We chose a food delivery platform (think Uber Eats, DoorDash, Glovo) because it's a domain complex enough
that different parts genuinely need different engineering approaches.

The domains we'll cover

Customer registration and restaurant onboarding. It's borderline CRUD, nothing fancy.

Restaurant order management and courier delivery flow.
A bit more complex, but straightforward if you approach it the right way.

Then you hit billing cycles, settlements, and payouts, plus tax calculation, invoicing, and document printing.
This is the fun part. Get it wrong and you can make your company bankrupt or get someone in legal trouble, and in some countries that's literal.

Don't worry if you're not an expert in accounting.
It's even better if you're not. When you land on a real project, you usually aren't.
We'll show you how to extract this kind of knowledge with Event Storming.

The API won't be a typical REST API. It's oriented around behaviors and commands, with use-case-based read models.

Some of these domains are CRUD. Others need careful modeling with aggregates protecting domain invariants.
Tax calculation has business rules that really matter.

You'll learn to tell the difference. That's the hard part, and that's what no other training teaches.

See the full agenda

Modular monolith, not microservices

How many trainings show you how to build a modular monolith? Almost none.

For teams under 20 people and project kickoffs, a modular monolith is often a faster way to ship.
You make changes faster, refactor with less friction, and it maps to microservices later if you need it to.

I've seen teams unable to ship because they started with overcomplicated microservices before they had 10 users.
Once you're deep in, it's months of work to change the approach.

We build this together, like a team

In a real project, nobody writes 20,000 lines alone. Same here.
You implement the parts that matter: the domain logic and the business rules, the places where your decisions actually matter.
We handle the rest. We've applied these patterns across many production projects and we know where
the theory breaks down. That experience shows up in every exercise.

It feels like working on an world-class team, not doing homework.
There are no deadlines, and you get guidance from us.
The patterns you practice here are much easier to apply in your own projects later.

Next time you face a complex domain at work, you won't be guessing where the boundaries should be.
You'll spot which parts of the domain need careful modeling and which ones are fine as CRUD.

It's not a training that only applies to a narrow set of projects

Our other training, "Go Event-Driven," is not for everyone: not every project needs event-driven architecture.
But what we cover in this training is different.
We can risk saying that every project can benefit from at least some of the patterns we teach.

You don't need to build business software to benefit from these patterns.
Many of them work even for designing games!

These skills make you a better engineer regardless of what you're building.

Your own IDE, your own tools

You work in your own IDE and terminal. VS Code, GoLand, whatever you prefer.
Nobody wants to work on a 20,000-line project in a browser.

Lack of practice is the biggest problem for people trying to learn patterns like these.
This is a coding-oriented training. Every piece of theory connects to practice.

Small exercises, each building on the last. You can make progress when you have 5 minutes a day.
Designed so you can fit it around work and family.

AI-friendly, but not AI-easy

The way we write software is changing, and I'm not here to tell you whether to write code by hand or not.
You can use any AI tool alongside the exercises if you want. Claude, Cursor, Copilot, whatever works for you.
Or write everything by hand to build muscle memory (we already limited the amount of code you write).

Even with AI, the exercises won't solve themselves.
We ship proper agent instructions, so the challenge is in your design decisions, not in copy-pasting exercise content.
What would be the point of that?

No other Go training offers this level of depth.
After the training, you'll have built a production-grade system where you made real architectural decisions:
when CRUD is enough, when you actually need advanced patterns, and you'll have structured modules that don't fight each other.

Join over 8,100 Go developers who have trained with us.

Sale runs until November 4. 30-day money-back guarantee. You risk nothing.

I'm joining The Domain Engineer

PS: We issue invoices. You can use your training budget and have your company cover the cost.
Add your TAX ID upon checkout. We also offer team discounts (10+ licenses).
Any questions? Reply to this email.

Best,

Miłosz