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. On Friday, August 18, 2017 at 6:47:22 AM UTC-4, Konstantin Khomoutov wrote: > > 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 > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
