Domain-driven design and go

[Hugo Torres]

Hi everybody,

Recently I've been reading "Domain Driven Design" and I think it has some useful stuff about organizing Go programs.

I wrote some of my thoughts up on my blog here.

Would love to know what everybody thinks.

Thanks,

Hugo

[Konstantin Khomoutov]

On Fri, Aug 18, 2017 at 03:29:01AM -0700, Hugo Torres wrote:

> Recently I've been reading "Domain Driven Design" and I think it has some
> useful stuff about organizing Go programs.
>
> I wrote some of my thoughts up on my blog here

> <https://juicemia.com/post/go-ddd/>.

>
> Would love to know what everybody thinks.

I'm not sure I got the point from reading.

What you have labelled as "Aggregates" is just a conventional
common-sense approach to structuring data: of course, a car "contains"
(hence "aggregates") its wheels.

What was labelled "Factories" are the standard ways to produce values of
types which do not have useful zero-values or just are convenient for
one reason or another. Examples of what you call "factories" are right
there in the go-to documents for Go beginners [1, 2].

What was labelled "Repositories" is a pretty standard way of decoupling
disparate parts of code by using an interface. Interfaces naturally
decouple the code which only relies on some behaviour from the code
which defines types implementing that behaviour.

I'm afraid you might be too dragged away by that shallow-water
theoretisation which appear to be done by this book.
As someone commented on Amazon, «Another meta-methodology book filled
with self-evident observations normally learned on the job. A lot of it
is just common sense.» — based on your blog post, it sounds just about
correct, sorry.

1. https://blog.golang.org/package-names
2. https://golang.org/doc/effective_go.html

[juicemia]

You're right. A lot of it is stuff you pick up as you grow your skills. I wrote the article to show how the Go community has standardized on patterns that were talked about in the book. I guess I could have done a better job of accentuating that.

I think a great example of that is the repository pattern. When I read the section on repositories I had already seen it in other Go applications I've worked on.

I'll be writing a follow up soon, i'll make sure to make that point more clear.

The thing about aggregates is that it isn't just about structuring data. It's about how you interact with the data.

A car "containing" its wheels falls short of explaining what an aggregate is.

The important thing about the aggregate is how its members are accessed, which is through the root object.

Also, there's a lot more to the book than just those three patterns. The first section of the book is entirely non-technical, and I think it's where most of the value in that book lies.

Thanks for the feedback.

[helloPiers]

This topic reminded me of this other thing I remember seeing: https://github.com/marcusolsson/goddd - there are some further links to blog posts and stuff on the README on that project, and there's a related talk on YouTube from one of the Go conferences. 

[juicemia]

Yeah that repo is really informative. I think it's a great source of info on the topic.