Domain Driven Design in Go

[marcusolsson]

For a while now I have been working on a project where I explore Domain Driven Design in Go as well as attempt to showcase of what an enterprise application, written in Go, could look like. I just published a blog post in order to hopefully get people from the community involved.

There is a lot more to be done, but I would love to get your feedback as well as bug reports

Read the article

Check out the project on Github

Also, try out the demo.

[Egon (Egon Elbre)]

Nice. It makes happy to see the article.

One of the things that somewhat bothers me is that the middleware package does a lot more than middleware. I suspect that you are missing a top-level package server (or app, not sure what a nice name would be) that ties the pieces together. (With some additional sub-packages for endpoints, i.e. server/track, server/admin, server/incidents)

Of course there is an alternative approach, to push those encoding/decoding pieces into their packages, so you would have inspection.Server, tracking.Server, booking.Server each handling their own encoding/decoding.

One will isolate the server, the other keeps the “idea” local. In this case I would probably go for the isolation part – otherwise the domain logic parts can start collecting accidental dependencies (e.g. user).

[marcusolsson]

Thanks

That’s a really good observation. I honestly hadn’t been given it much thought until now, but I think you’re absolutely right about extracting a server package. As much as possible, I would like to keep net/http from the domain packages so I would definitely prefer having the subpackages-within-server-approach.

I think that would also be the end of the middleware package since the logging and proxying would reside in the corresponding endpoint package.

server/
    booking/
        logging.go
        proxying.go
        transport.go // encoding/decoding
        endpoint.go // MakeBookingEndpoint
    handling/
    tracking/