[m110]

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.

[mattgreenrocks]

> you would keep a "pure" layer of domain code that does just that.

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.

[hardwaresofton]

> 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]

Ah, I get it now. You meant in in the context of onion/clean/hexagonal architecture. :)

[hardwaresofton]

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

[Serow225]

I think that's not uncommon to happen, because there's definitely overlap in the communities/people talking about this stuff. Using/thinking in DDD tends to lead naturally towards onion/hex/ports-and-adapters (whatever you want to call it)

[m110]

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.

[sagichmal]

> go-kit is very far away from DDD.

Bizarre. Go kit is basically the reference model for DDD in Go.