I built a large enterprise website in go, and I can say that I barely ever even had to consider the lack of generics. Occasional slightly annoying interface shenanigans and mild interface hackery, but nothing significant at all.
Did you have to do a lot of stuff that is DDD-related? Like building out abstractions for adapters and connection points, or did you use libraries that did that part for you mostly? I know of some stuff out there like go kit[0] which is quite pragmatic and does some of the 80% use-cases (serialization, transports, etc) DDD stuff for you.
I think for the most part it's rare to actually need to write a lot of your own DDD pieces for CRUD-y apps, and the parts where the complexity would be worth it are often already done for you by the libraries/frameworks used.
[0]: https://gokit.io/
For CRUD-y apps, you usually wouldn't need the DDD patterns at all, as there's no complex business logic to model.
> the parts where the complexity would be worth it are often already done for you by the libraries/frameworks used.
I'm really confused about this. The most complexity comes from complex business scenarios you need to handle somehow in code. No framework is flexible enough to do it for you. Using DDD, you would keep a "pure" layer of domain code that does just that.
Paradoxically, I think you might actually be mixing some stuff up -- the only reason you can "focus on your business logic" is because the stuff at the edges is taken for you. DDD is the way of thinking that strives to let people focus on business logic by separating and abstracting the non-business layers. If you look for "ddd onion" you'll see the usual images of how this works.
Go kit is valuable because it adheres to this. For example:
> Pluggable serialization and transport — not just JSON over HTTP
This is basically what pragmatic DDD looks like. Worry about what you need to say (the business logic), not how it's said.
> For CRUD-y apps, you usually wouldn't need the DDD patterns at all, as there's no complex business logic to model.
Agreed on this -- this is why I asked whether the app was mostly CRUD-y or not.
> I'm really confused about this. The most complexity comes from complex business scenarios you need to handle somehow in code. No framework is flexible enough to do it for you. Using DDD, you would keep a "pure" layer of domain code that does just that.
Ahh, that quote was referring to a mostly CRUD-y app -- as in I was noting how how DDD would not be useful in a mostly CRUD app (as you've noted, it isn't) mostly because it's already done for you (ex. go kit).
I think the advantage of sticking to a specific "architecture" pattern is you don't waste time discussing where to put what, you just agree to one way and do it.
This is pretty much the only way I write 'business' software now. Even for small apps domain complexity gets gummed up with presentation/side effects really fast and I have a hard time disentangling them in my mind. Worth noting: most business apps I've worked on really don't have a lot of external dependencies, but those dependencies tend to sprawl out over the code quickly.
I'm really glad to see this approach getting traction in various forms (hexagonal programming, FP effect systems, Redux-style reducers) and don't have much of a horse in the race other than an abstract notion of a pure component, which may or may not be stateful, that accepts and sends a domain-specific set of messages and events.
Bizarre. Go kit is basically the reference model for DDD in Go.
I'm not sure I'm on the same page here but we often use Repository Pattern were abstractions are needed (obvious example would be some data storage).
We don't have too many libraries in our code. No DDD stuff for sure.
CRUDy apps basically mean you have some domain related structs and a few database methods to connect those structs to data.
> CRUDy apps basically mean you have some domain related structs and a few database methods to connect those structs to data.
Yup fully agreed here -- I was trying to see if there were cases where they poster had to build the abstractions you'd want for a DDD-like system. Normally you don't have to so I was wondering if their experience matched up with my ideas about DDD to start with.
In that area, you might want to also check out:
- https://github.com/goadesign/goa
- https://github.com/emicklei/go-restful
For example, a few years ago, I was a big fan of how C# was dealing with persistence via so-called micro-ORMs vs the massive ORMS that most other languages fixated on.