Golang and DDD domain modeling

type Realm struct { base.Entity FriendlyName FriendlyName } type CreateRealmParams struct { FriendlyName string } func CreateRealm(id base.EID, params *CreateRealmParams) (*Realm, error) { var err error var r = new(Realm) r.Entity = base.NewEntity(id) r.FriendlyName, err = NewFriendlyName(params.FriendlyName) return r, err } type FriendlyName struct { value string } var ErrInvalidFriendlyName = errors.New("invalid friendly name") func (n FriendlyName) String() string { return n.value } func NewFriendlyName(input string) (FriendlyName, error) { if input == "" { return ErrInvalidFriendlyName } // perhaps some regexp rule here... return FriendlyName{value: input}, nil }

type Realm struct { base.Entity FriendlyName string } type CreateRealmParams struct { FriendlyName string } func CreateRealm(id base.EID, params *CreateRealmParams) (*Realm, error) { var err error if err = validateFriendlyName(params.FriendlyName); err != nil { return nil, err } entity := base.NewEntity(id) return &Realm{ Entity: entity, FriendlyName: params.FriendlyName, }, nil }

type Realm struct { base.Entity friendlyName string } type CreateRealmParams struct { FriendlyName string } func CreateRealm(id base.EID, params *CreateRealmParams) (*Realm, error) { var err error if err = validateFriendlyName(friendlyName); err != nil { return nil, err } entity := base.NewEntity(id) return &Realm{ Entity: entity, friendlyName: friendlyName, }, nil } func (r *Realm) FriendlyName() string { return r.friendlyName } func (r *Realm) SetFriendlyName(input string) error { if err := validateFriendlyName(input); err != nil { return err } r.friendlyName = input return nil }

First of all, as other commenters rightfully say, you have to look at the goals of DDD and decide whether the approach has merit. DDD adds some complexity to the architecture (most of that in the initial phase when structuring your project and base types) and the amount of boilerplate and ceremony you'll have to deal with after that.

In many cases simpler designs, e.g. a CRUD approach, work best. Where DDD shines is in applications that are in themself more complex in terms of functionality and/or where the amount of features is expected to significantly grow over time. Technical advantages can come in terms of modularity, extensibility and testability, but - most importantly imho - providing a process in which you can take the non-technical stakeholders along and translate their wishes to code without losing them along the way.

There's a great series of blog posts, the Wild Workouts Go DDD Example, that takes you along a refactoring process of a traditional Go CRUD-based REST API design to a full-blown DDD architecture, in several steps.

Robert Laszczak, author of the series defines DDD as follows:

Ensure that you solve valid problems in the optimal way. After that implement the solution in a way that your business will understand without any extra translation from technical language needed.

And he sees Golang + DDD as the excellent way to write business applications.

Key to understand here is to decide how far you want to go (no pun intended) with your design. The refactoring gradually introduces new architecture concepts, and at each of these steps you should decide if it is enough for your use case, weigh the pros and cons to go further. They start very KISS with a DDD Lite version, and then later go further with CQRS, Clean Architecture, Microservices and even Event Sourcing.

What I see in many projects is that they immediately go the Full Monty, creating overkill. Especially Microservices and Event Sourcing add a lot of (accidental) complexity.

I am not well-versed in Go yet (actually quite new to the language), but'll give a stab at your options and offer some considerations. Maybe more experienced Go developers can correct me, where I go off-the-mark :)

For my own project I am looking into a Clean Architecture (Ports & Adapters, Inversion of Control) + CQRS + DDD combination.

The Wild Workouts example provides ample inspiration, but will need some tweaks and additions here and there.

My goal is that in the codebase's folder structure developers should immediately recognize where features / use cases (epics, user stories, scenario's) reside, and have self-contained, fully consistent domains that directly reflect the Ubiquitous Language and are separately testable. Part of testing will be text-only BDD scripts that can be easily understood by customer and end-users.

There will be some boilerplate involved, but - given the above - I think the pros outweigh the cons (if your application warrants DDD).

Your Option #1 looks best to me, but with some additional observations (note: I will stick to your naming, which will make some of this seem overkill.. again it is the ideas that count).

Instead of Entity I would say that Realm represents an AggregateRoot.
This can be implicitly so, or it can inline a base.AggregateRoot.
The aggregate root is the access point to the domain, and ensures its state is always consistent.
Hence the internal state of Realm should be immutable. State changes occur via functions.
Unless really trivial and not likely to change I'd implement FriendlyName value object in a separate file.
Also part of the domain is a RealmRepository but this provides no more than an interface.

Now I'm using CQRS, which is an extension to what's shown in your code snippets. In this:

There might be a ChangeFriendlyName Command handler in the Application layer.
The handler has access to a repository implementation e.g. InMemRealmRepository.
Might pass a CreateRealmParams to the Command, which then does its validation.
Handler logic might start by fetching a Realm aggregate from the database.
Then constructs a new FriendlyName (can also encapsulate in a Realm function call).
A function call to Realm updates state and queues a FriendlyNameChanged event.
The command handler persists the changes to the InMemory database.
Only if there were no errors the command handler invokes Commit() on the aggregate.
One or more queued events are now published e.g via an EventBus, handled where needed.

As for the code of Option #1 some changes (hope I'm doing this right) ..

realm.go - Aggregate root

type Realm struct {
   base.AggregateRoot

   friendlyName FriendlyName
}

// Change state via function calls. Not shown: event impl, error handling.
// Even with CQRS having Events is entirely optional. You might implement
// it solely to e.g. maintain an audit log.
func (r *Realm) ChangeFriendlyName(name FriendlyName) {
   r.friendlyName = name
   
   var ev = NewFriendlyNameChanged(r.id, name)

   // Queue the event.
   r.Apply(ev)
}

// You might use Params types and encapsulate value object creation,
// but I'll pass value objects directly created in a command handler.
func CreateRealm(id base.AID, name FriendlyName) (*Realm, error) {
   ar := base.NewAggregateRoot(id)

   // Might do some param validation here.

   return &Realm{
       AggregateRoot: ar,
       friendlyName: name,
   }, nil
}

friendlyname.go - Value object

type FriendlyName struct {
    value string
}

// Domain error. Part of ubiquitous language.
var FriendlyNameInvalid = errors.New("invalid friendly name")

func (n FriendlyName) String() string { return n.value }

func NewFriendlyName(input string) (FriendlyName, error) {
    if input == "" {
        return FriendlyNameInvalid
    }
    // perhaps some regexp rule here...

    return FriendlyName{value: input}, nil
}

Recommended topics

Hot tags