#domain-driven design

Unlike (some) other programming languages in Go reflection is considered ok for using it in production code. Which does not mean it should be used without a good reason.

I tried to implement a command handler in a different way than switch/case given the interface of the command handler can stay as it is:

type CommandHandler interface { Handle(command Command) error }

The advantage of having a single entry point is that it’s simple to wrap each handled command with generic functionality, e.g. transactional stuff. The only disadvantage of using a switch/case it that this is quite ugly, especially if the command handler grows and has to handle lot’s of commands.

Obviously I tried to solve this with reflection and I got it working:

package application import ( "errors" "myproject/customer/model" "myproject/customer/model/commands" "myproject/shared" "reflect" ) type commandHandlerWithReflection struct { customers model.Customers } func NewCommandHandlerWithReflection(persons model.Customers) *commandHandlerWithReflection { return &commandHandlerWithReflection{customers: persons} } func (handler *commandHandlerWithReflection) Handle(command shared.Command) error { if command == nil { return errors.New("commandHandler - nil command handled") } method, ok := reflect.TypeOf(handler).MethodByName(command.CommandName()) if !ok { return errors.New("commandHandler - unknown command handled") } in := make([]reflect.Value, 2) in[0] = reflect.ValueOf(handler) // method receiver in[1] = reflect.ValueOf(command) // first input param - the command response := method.Func.Call(in) switch response[0].Interface().(type) { case error: return response[0].Interface().(error) case nil: return nil default: return errors.New("commandHandler - unexpected type returned when command was handled") } } func (handler *commandHandlerWithReflection) Register(register commands.Register) error { newCustomer := model.NewUnregisteredCustomer() if err := newCustomer.Apply(register); err != nil { return err } if err := handler.customers.Save(newCustomer); err != nil { return err } return nil } func (handler *commandHandlerWithReflection) ConfirmEmailAddress(confirmEmailAddress commands.ConfirmEmailAddress) error { customer, err := handler.customers.FindBy(confirmEmailAddress.ID()) if err != nil { return err } if err := customer.Apply(confirmEmailAddress); err != nil { return err } if err := handler.customers.Save(customer); err != nil { return err } return nil }

But there is one issue with that solution: The methods which the Handle() method dispatches to should be private, as they are not part of the public interface!

Even if NewCommandHandlerWithReflection() would return an interface instead of the concrete object, which is not idiomatic in Go (and I will only bend this rule with a very good reason), any client of the command handler could still simply typecast it to the concrete object.

Unfortunately Go's reflection does not support unexported methods. The conceptual reason is that this would render the whole exported/unexported paradigm quite useless. I wish it would support that from within the same package, like in my usecase. There might be technical reasons apart from conceptual reasons, though.

So once more when I played with reflection in Go it did not end up in an acceptable solution, but at least I have learned how to do it. ;-)

I recently joined the Domain-Driven Design group on LinkedIn Domain Driven Design and the group owner David asked me:

"How do you like golang? Any features of go that make it work well with DDD or micrososervices?"

So here we go, I'll use that stimulus to start blogging again.

A bit about my background and history with Go

Before I started programming with Golang in my last company I did PHP for almost 2 decades (true story). Last PHP version I worked with was PHP 7.0, which had all relevant features to do SOLID OOP, with the exception of strict typing (that was added later). My team was switched to a new greenfield project working with Go, in a Microservice environment. We did DDD with EventSourcing from the start. Some more tech stack namedropping: Kafka, PostgreSQL, Docker, Kubernetes - backend services talking RPC with "go-micro" as their framework.

Now we had a similar journey getting into Go as many other devs who were also coming from OOP, we started trying to turn Go into OOP, which is generally not a good idea. Actually, if you favour "composition over inheritance" there is not SO much of a difference, at least to PHP (PHP has no generics, no method overloading, no other OOP Voodoo). Most of the differences lie in what's idiomatic in Go, which can savely be ignored given developers make educated decisions, for example by declaring higher level concepts more important than language concepts.

Some details about Go and it's challenges

There is one important difference to OOP languages, which is how interfaces work in Go. You don't declare an object in Go to be implementing an interface, instead it's "duck typed". So anyhing that fulfills all method signatures of some interface just magically implements it. In Go it's common to not define interfaces on the implementation but on the client side, or put other way, every client using the implementation of some service can bring it's own interface and use interface segregation (e.g. if only a portion of the service's methods are needed). I totally like that, but it conflicts a bit with hexagonal architecture aka. ports and adapters. Luckily this is a case of "idiomatic Go", so here's our good reason to ignore that. As an example, in DDD you would define the interface for a Repository or a DomainService in the Domain package, in Go you would define it where it's used, e.g. in the Application package.

Some other common ways of doing things in Go are probably not even described as "idiomatic", e.g. creating objects like structs on the fly without using factory methods, which is only possible if the internals of such a struct are public (Go calls it exposed). As DDD practitioners we want our ValueObjects immutable, so we'll keep our stuff private and have proper factory methods.

I plan to write about how I would implement things (VOs, Entities, etc.) in Go nowadays - after 2.5 years of learning and changing my mind back and forth at least 5 times about every detail.

My friend James has blogged about BYPASSING GOLANG'S LACK OF CONSTRUCTORS which he could also have named "How can I avoid all those nil pointer checks in Go?", it's very interesting!

Spoiler alert -> With quite some effort you ... still can't fully avoid those nil pointer checks (but there are some ideas how to reduce them)

What makes Go a good fit for DDD / Microservices

Speed

There are faster languages around, but Go runs fast and it compiles very fast, mostly because of the simplicity of the language. And it's getting faster, afaik mostly because of improvements in the garbage collector. For people like me - coming from an interpreted language like PHP or Python - it's fast as lightning, which raises the bar for (premature) performance optimisations quite high. I profiled our stuff a while ago and there was no worthwile target for optimisations in our event-sourced application (unmarshalling was the biggest "thing" but only accounted for around 10% of runtime). To give a rough idea about speed - we could easily serve any command that did not have to make synchronous calls to other external services under 10 ms. With full reconstitution of the Aggregate, no snapshotting or other caching involved.

Simplicity

As Microservices tend to be small they also tend to be relatively simple (this is for sure a simplification), so a language with simplicity as a core concept is a natural fit. I'll put another fact into this catogory, which is the lack of sophisticated frameworks, ORMs, etc. For sure frameworks and ORMs exist, but they tend to be more lightweight and none of them is a de-facto standard which you have to use because everybody does it and then suddenly you're spending more time fighting the accidential complexity of such things instead of solving your domain challenges.

Concurrency

I totally love Go's way of concurrency with goroutines and channels to synchronise them if necessary. As an example, we have implemented a very efficient and hight throughput event publisher, which publishes Domain Events after they were commited to the Event Store. Often all you need is to fire and forget a goroutine to do things that must not block your main application flow, e.g. sending notifications (emails) given it's not critical if the sending fails.

Summary

Even if you have the benefit of working with a ton of people who are much smarter than you, keeping everyone on the same page while developing or iterating on models is a challenge.

I have a bunch of thoughts about domain-driven design, ubiquitous language, (in particular about behavior driven development) that I’d like to write about but I’ll probably never make the time.

So here’s a quick summary.

This talk by Adrian Cockcroft about composing and deploying microservices is pretty good. The talk introduced me to Domain Driven Design by Eric Evans, which I’m still making my way through. So far the book claims that it will describe a process for developing a model and ubiquitous language regarding that model, and that these tools make it easier to collectively discuss and reason about it, but I haven’t read enough to have formed an opinion on the particular method yet.

Friend of mine, Paweł, has recently shared few very interesting recordings of presentations about microservices architecture. Follow to his blog posts to learn from the best what microservices architecture is about and how it can make your team be even…

via elegantcode.com