| > 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). |