Hi, I usually use the following project structure:
ui service >>domain 1 >>domain 2 business (or domain) >>domain 1 >>domain 2 data (or infrastructure) >>domain 1 >>domain 2 utilities >>domain 3 >>domain 4 So they are separated by domain, rather than aggregates. My friend prefers the following structure: ui domain 1 >>service >>business >>data domain 2 >>service >>business >>data utilities There is no right or wrong answer. Just use whatever works for your project. However, lumping everything into one folder is usually a bad idea for a larger project. On Tuesday, November 1, 2016 at 2:02:53 AM UTC+7, JM wrote: > im building a micro service layer using the following folder structure. I > have unit tests for everything and each if store in it's relative folder. > I am thinking of moving everything in my domain model into one root folder > and not have sub folders for each. then just have NewAggregate1 instead of > New() since all will be under the same package. Is this bad design, I > assume so since their is no clear separation between aggregates, but wanted > to get opinions. How can i run my tests "go test" for my entire domain > model is they are in sub folders? Right now i only know how to do this per > folder level. Thanks. > > application (application services that wrap everything) > command (command services) > query (query logic outside of domain) > common > domainmodel > >>shared > >>aggregate1 > >>aggregate2 > infrastructure > >>logging > >>config > >>repository > service (micro services) > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
