10 ms·

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 she

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.

hardwaresofton 5y ago
Thanks for mentioning this experience -- I was really excited about Go early on but went with other languages after a while so didn't make any huge projects with it (and definitely not at a large employer/go shop). 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/ https://gokit.io/
- llimllib 5y ago
  I’m not the authors and don’t even really know what ddd means, sorry
  - hardwaresofton 5y ago
    No problem -- "DDD" refers to Domain Driven Design[0] [0]: https://en.wikipedia.org/wiki/Domain-driven_design https://en.wikipedia.org/wiki/Domain-driven_design
- m110 5y ago
  I think you mix some things up. go-kit is very far away from DDD. It even says on their website: "Focus on your business logic.". It's basically everything but not the domain code. 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.
  - hardwaresofton 5y ago
    > I think you mix some things up. go-kit is very far away from DDD. It even says on their website: "Focus on your business logic.". It's basically everything but not the domain code. 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).
    - m110 5y ago
      Ah, I get it now. You meant in in the context of onion/clean/hexagonal architecture. :)
      - hardwaresofton 5y ago
        yeah! Am I using the a better name for this? I thought of it as "DDD" but maybe I should call it the onion/hexagonal architecture in conversation from now on to make sure the right point gets across
        m110 5y ago
        I think it's probably closer to the onion architecture, as DDD doesn't concern much about infrastructure. But it's kind of mixed up. You could also call it just SRP or separation of concerns. 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.
- konart 5y ago
  >Like building out abstractions for adapters and connection points 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.
  - hardwaresofton 5y ago
    Yeah you are -- repository pattern, maybe some built-in serializers/adapters is what I'd expect to be the extent of DDD for most CRUD-y projects. Generally the less libraries/frameworks the better. > 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.
- mattgreenrocks 5y ago
  GoKit looks fantastic, thanks for mentioning that. It is very close to my imagined platonic ideal of writing business logic wholly separate from all the side effecting glue code.
  - hardwaresofton 5y ago
    No problem! I'm not a go dev so there's probably much better stuff out there, but I take note of good stuff when I see it, no matter the language. In no particular order: In that area, you might want to also check out: - https://github.com/goadesign/goa https://github.com/goadesign/goa - https://github.com/emicklei/go-restful https://github.com/emicklei/go-restful - https://github.com/asim/go-micro https://github.com/asim/go-micro - https://github.com/ribice/gorsk https://github.com/ribice/gorsk
    - mattgreenrocks 5y ago
      I like the sentiment. As I get older I find it more interesting to hoard good ideas, which often requires keeping up with multiple ecosystems at once, as each ecosystem has a different set of aesthetics. 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.
hajhatten 5y ago
I've had the same experience building both big and small systems. It's a feature of go, not something that's missing imo.

hardwaresofton 5y ago

Thanks for mentioning this experience -- I was really excited about Go early on but went with other languages after a while so didn't make any huge projects with it (and definitely not at a large employer/go shop). 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/ https://gokit.io/

llimllib 5y ago
I’m not the authors and don’t even really know what ddd means, sorry
- hardwaresofton 5y ago
  No problem -- "DDD" refers to Domain Driven Design[0] [0]: https://en.wikipedia.org/wiki/Domain-driven_design https://en.wikipedia.org/wiki/Domain-driven_design
m110 5y ago
I think you mix some things up. go-kit is very far away from DDD. It even says on their website: "Focus on your business logic.". It's basically everything but not the domain code. 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.
- hardwaresofton 5y ago
  > I think you mix some things up. go-kit is very far away from DDD. It even says on their website: "Focus on your business logic.". It's basically everything but not the domain code. 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).
  - m110 5y ago
    Ah, I get it now. You meant in in the context of onion/clean/hexagonal architecture. :)
    - hardwaresofton 5y ago
      yeah! Am I using the a better name for this? I thought of it as "DDD" but maybe I should call it the onion/hexagonal architecture in conversation from now on to make sure the right point gets across
      - m110 5y ago
        I think it's probably closer to the onion architecture, as DDD doesn't concern much about infrastructure. But it's kind of mixed up. You could also call it just SRP or separation of concerns. 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.
konart 5y ago
>Like building out abstractions for adapters and connection points 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.
- hardwaresofton 5y ago
  Yeah you are -- repository pattern, maybe some built-in serializers/adapters is what I'd expect to be the extent of DDD for most CRUD-y projects. Generally the less libraries/frameworks the better. > 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.
mattgreenrocks 5y ago
GoKit looks fantastic, thanks for mentioning that. It is very close to my imagined platonic ideal of writing business logic wholly separate from all the side effecting glue code.
- hardwaresofton 5y ago
  No problem! I'm not a go dev so there's probably much better stuff out there, but I take note of good stuff when I see it, no matter the language. In no particular order: In that area, you might want to also check out: - https://github.com/goadesign/goa https://github.com/goadesign/goa - https://github.com/emicklei/go-restful https://github.com/emicklei/go-restful - https://github.com/asim/go-micro https://github.com/asim/go-micro - https://github.com/ribice/gorsk https://github.com/ribice/gorsk
  - mattgreenrocks 5y ago
    I like the sentiment. As I get older I find it more interesting to hoard good ideas, which often requires keeping up with multiple ecosystems at once, as each ecosystem has a different set of aesthetics. 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.

hajhatten 5y ago

I've had the same experience building both big and small systems. It's a feature of go, not something that's missing imo.