Skip to content

zhuravlevma/golang-ddd-architecture

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

73 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

DDD patterns with examples

Implementation of DDD patterns in Golang

Marketplace Domain

Event Storming schema

image

Describe

Bounded Contexts:

  • Warehouse - Context for warehouse operations

    • Subdomains: -
      • Core OrderManagement - order management at the warehouse
      • Supporting Location - management of product locations at the warehouse, product categorization
  • Accounting - accounting context

    • Subdomains: -
      • Core Reports - financial reports generation
      • Supporting Verification - order verification
  • Delivery - delivery context

    • Subdomains: -
      • Core Board - board of order proposals
      • Core Couriers - management of couriers
      • Supporting Tracking - delivery status tracking

Module boundaries

This project is a large monolith structured at a high level into bounded contexts. Each context contains subdomains that, depending on the type, implement their architectural pattern. For the Core subdomain, a Domain model is chosen, while for the Supporting subdomain, either Transaction script or Active Record is implemented as its architectural pattern.

  • Domain model: Core

    Domain model with a clean architecture with ports and adapters. It takes into account some tactical patterns from DDD.

    domain model schema
  • Active Record: Generic/Supporting

    Active Record uses the most obvious approach, putting data access logic in the domain object.

    active record schema
  • Transaction Script: Generic/Supporting

    Transaction Script organizes business logic by procedures where each procedure handles a single request from the presentation.

    transaction script schema

If you have a large monolith that contains many bounded contexts, then the service can be divided into modules by context.

If you have a micro service architecture and you prefer to allocate contexts to different services (which is preferable). If it's not enough for you, then you can also divide subdomains into services. Each Core subdomain can be divided into modules by aggregates.

Why do I need an event bus?

Firstly, we have a limitation - this is the change of one aggregate in one transaction (strong consistency). To change multiple aggregates at the same time, you need to use eventual consistency.

Why do I need Relay?

We cannot write a message directly to the broker, because it may not be available. Pattern Transactional outbox.

Transactional outbox can be done using synchronous calls, the broker is not biased. But this option is more suitable for point-to-point communication.

In a good way, each bounded context in a micro-service architecture should have its own Relay. In the demonstration monolith, I decided to limit myself to one.