You write CQRS. You talk about aggregates. You emit domain events. But where do these concepts come from? Domain-Driven Design. Without understanding DDD, CQRS is just a pattern you copy-paste and hope it holds. With DDD, it becomes a tool you use consciously, for the right reasons. This article lays the conceptual foundations. The concrete terrain: a Go service consuming APIs from multiple crypto exchanges (Binance, OKEx, Coinbase). Because an Order in trading is something any trader understands — that's exactly the kind of domain where DDD pays off. DDD's core principle is uncomfortable when you come from a technical background: the business model takes precedence over technology. You don't start with "what database", or "what API does Binance expose". You start with "what is an Order in this system? What is a Position? What happens when an order is partially filled?" For a crypto trading service, the domain is: orders you place, positions that evolve, market data arriving continuously, a portfolio whose value you monitor. Not "a Binance wrapper". Not "a websocket consumer". Those are implementation details. The practical difference: if your model is domain-centric, you can replace Binance with OKEx without touching your business logic. If your model is API-centric, you rewrite everything every time an exchange changes an endpoint. DDD doesn't say "ignore technology". It says "don't let technology contaminate your business model". This is the most practical DDD concept, and the most frequently misunderstood. A bounded context is an explicit boundary inside which a model has a precise, coherent meaning. Outside that boundary, the same word can mean something different — and that's acceptable. For a crypto trading service, three natural bounded contexts emerge: Prices, order books, tickers, recent trades. This context is read-heavy, near real-time. Binance can push 10 updates per second on BTC/USDT. The model here is simple: immutable snapshots. A Ticker in Market Data has no mutable state — it's just a value at a point in time. Orders, executions, positions. This context is command-heavy. An Order here has a full lifecycle: created, submitted, partially filled, cancelled. Business logic is concentrated here: validation rules, exchange rejection handling, fee calculation. This is where your aggregates live. Balances, P&L, trade history. This context is a read model oriented toward reporting. It consumes events emitted by Trading to maintain a coherent view of the portfolio. Updates can be slightly delayed — a few seconds of lag is acceptable for reporting. Why separate them? Because they have radically different constraints. Market Data at 10 updates/sec doesn't need the same model as Portfolio reporting aggregating data over 3 months. Putting everything in the same model means making compromises that make everything more complex without any benefit. Bounded Context Load Consistency Business complexity Market Data Very high (websockets) Eventual OK Low Trading Moderate (commands) Strong (transactional) High Portfolio Low (read model) Eventual OK Low Two core DDD building blocks that Go implements naturally, without any framework. A Value Object is immutable. Its identity is defined by its value, not by a reference. Price{Amount: 42000, Currency: "USD"} equals another Price with the same fields. In Go, this translates to a struct without a pointer, passed by value. // Value Object — immutable, equality by value type Price struct { Amount decimal.Decimal Currency string } func (p Price) IsZero() bool { return p.Amount.IsZero() } func (p Price) Add(other Price) (Price, error) { if p.Currency != other.Currency { return Price{}, fmt.Errorf("currency mismatch: %s vs %s", p.Currency, other.Currency) } return Price{Amount: p.Amount.Add(other.Amount), Currency: p.Currency}, nil } type TradingPair struct { Base string // "BTC" Quote string // "USDT" } func (tp TradingPair) String() string { return tp.Base + "/" + tp.Quote } An Aggregate is a unit of consistency. All modifications go through its methods — never through direct field access. It guarantees that its business invariants are always upheld. And in event sourcing, it emits events to describe what happened. type OrderStatus int const ( StatusPending OrderStatus = iota StatusPartial StatusFilled StatusCancelled ) // Aggregate — consistency guaranteed, modification through methods only type Order struct { id OrderID pair TradingPair side Side // Buy / Sell quantity decimal.Decimal filledQty decimal.Decimal status OrderStatus events []DomainEvent } func NewOrder(pair TradingPair, side Side, qty decimal.Decimal) (*Order, error) { if qty.IsZero() || qty.IsNegative() { return nil, fmt.Errorf("invalid quantity: %s", qty) } o := &Order{ id: NewOrderID(), pair: pair, side: side, quantity: qty, status: StatusPending, } o.events = append(o.events, OrderCreated{ OrderID: o.id, Pair: pair, Side: side, Qty: qty, }) return o, nil } func (o *Order) Fill(qty decimal.Decimal, price Price) error { if o.status != StatusPending && o.status != StatusPartial { return ErrOrderNotFillable } if qty.GreaterThan(o.quantity.Sub(o.filledQty)) { return fmt.Errorf("fill qty %s exceeds remaining %s", qty, o.quantity.Sub(o.filledQty)) } o.filledQty = o.filledQty.Add(qty) if o.filledQty.Equal(o.quantity) { o.status = StatusFilled } else { o.status = StatusPartial } o.events = append(o.events, OrderFilled{ OrderID: o.id, Qty: qty, Price: price, }) return nil } func (o *Order) Cancel() error { if o.status == StatusFilled || o.status == StatusCancelled { return ErrOrderAlreadyTerminal } o.status = StatusCancelled o.events = append(o.events, OrderCancelled{OrderID: o.id}) return nil } // Events are retrieved then purged after persistence func (o *Order) PopEvents() []DomainEvent { events := o.events o.events = nil return events } Notice what's absent: no database access, no HTTP calls, no external dependencies. The aggregate is pure Go. It expresses business rules and generates events — that's it. Persistence is someone else's problem. Binance returns prices as strings: "4.00000000". OKEx uses a different format. Coinbase yet another. If you let these external formats leak into your domain, you have a problem: your model becomes dependent on the whims of three different exchanges. The Anti-Corruption Layer (ACL) is the translation boundary. Outside: the exchange's model. Inside: your domain. The ACL translates, and your domain never hears about Binance. // External model — what Binance actually sends type binanceOrderBook struct { LastUpdateID int64 `json:"lastUpdateId"` Bids [][]string `json:"bids"` // [["price", "qty"], ...] Asks [][]string `json:"asks"` } // ACL: translates Binance model to domain func (c *BinanceClient) GetOrderBook(ctx context.Context, pair TradingPair) (*domain.OrderBook, error) { raw, err := c.fetchRaw(ctx, pair.String()) if err != nil { return nil, fmt.Errorf("binance order book %s: %w", pair, err) } return translateBinanceOrderBook(raw) } func translateBinanceOrderBook(raw *binanceOrderBook) (*domain.OrderBook, error) { bids := make([]domain.PriceLevel, 0, len(raw.Bids)) for _, b := range raw.Bids { if len(b) != 2 { return nil, fmt.Errorf("unexpected bid format: %v", b) } price, err := decimal.NewFromString(b[0]) if err != nil { return nil, fmt.Errorf("invalid bid price %q: %w", b[0], err) } qty, err := decimal.NewFromString(b[1]) if err != nil { return nil, fmt.Errorf("invalid bid qty %q: %w", b[1], err) } bids = append(bids, domain.PriceLevel{ Price: domain.Price{Amount: price, Currency: "USDT"}, Quantity: qty, }) } // same for asks... return &domain.OrderBook{Bids: bids}, nil } And for OKEx, the same interface, a different translation: // External OKEx model — completely different format type okexOrderBook struct { Data []struct { Asks [][]string `json:"asks"` // [["price", "qty", "liquidated", "count"], ...] Bids [][]string `json:"bids"` Timestamp string `json:"ts"` } `json:"data"` } func (c *OKExClient) GetOrderBook(ctx context.Context, pair TradingPair) (*domain.OrderBook, error) { raw, err := c.fetchRaw(ctx, pair) if err != nil { return nil, fmt.Errorf("okex order book %s: %w", pair, err) } return translateOKExOrderBook(raw) } Your trading code has no idea who's providing the order book. It calls an OrderBookProvider interface and receives a domain.OrderBook. If Binance changes its API from v3 to v4 with a new response format, only translateBinanceOrderBook changes. Zero impact on business logic. // Interface defined by the domain — not by the exchanges type OrderBookProvider interface { GetOrderBook(ctx context.Context, pair TradingPair) (*OrderBook, error) } // The trading service has no dependency on Binance, OKEx or Coinbase type TradingService struct { orderBook OrderBookProvider orderRepo OrderRepository } If you've read the articles on CQRS aggregates and command handlers, you've already seen DDD in action without it being explicitly named. DDD gives you the model: aggregates, Value Objects, domain events, bounded contexts. CQRS is the architectural pattern that exploits that model. The relationship is direct: A Command expresses a business intent (PlaceOrder, CancelOrder) The command handler loads the aggregate, calls a business method The aggregate validates the invariant and emits a DomainEvent The event is persisted, then propagated to read models (Portfolio, history) // Command — business intent type PlaceOrderCommand struct { Pair TradingPair Side Side Quantity decimal.Decimal } // Handler — orchestrates without business logic func (h *PlaceOrderHandler) Handle(ctx context.Context, cmd PlaceOrderCommand) error { order, err := domain.NewOrder(cmd.Pair, cmd.Side, cmd.Quantity) if err != nil { return fmt.Errorf("invalid order: %w", err) } // Submit to exchange via ACL exchangeID, err := h.exchange.SubmitOrder(ctx, order) if err != nil { return fmt.Errorf("exchange submission: %w", err) } order.SetExchangeID(exchangeID) // Persist the aggregate and its events return h.orderRepo.Save(ctx, order) } Without DDD, the command handler accumulates business logic. With DDD, it orchestrates: load, call, persist. The logic belongs to the aggregate. DDD adds complexity. Abstraction layers, interfaces everywhere, translations between models. On a simple CRUD service — user list, a few REST endpoints, no complex business rules — it's clear over-engineering. For a crypto trading engine with business rules spanning multiple exchanges, invariants to maintain, divergent external formats, and logic that evolves with the market — it pays off. The cost of abstraction is offset by the ability to change one piece without bringing down the others. The most honest test: if a domain expert — a trader — can read your code and recognize their business concepts, DDD is working. If your code talks about BinanceWebsocketMessageParser and RestAPIResponseDTO, you've let technology invade the domain. DDD is not an architecture, it's a modeling philosophy. It says: code should speak the language of the people who understand the problem, not the language of the people who understand the technology. In a crypto trading service, that means Order, Position, TradingPair — not BinanceResponseWrapper. Bounded contexts provide the structure. Aggregates provide consistency. Anti-Corruption Layers provide isolation. And when you add CQRS on top, you have a system where each part has a clear responsibility and explicit boundaries. Next time you write a command handler, ask yourself: does this logic belong in the handler or in the aggregate? If the answer is "in the aggregate", you're doing DDD.