按技术职责还是按领域职责来构建代码？Reddit

　　在构建RESTapi时，您会选择：
　　选项A：controllersorder。goregion。gouser。gomodelsorder。goregion。gouser。goreposorder。goregion。gouser。go
　　选项B：orderordercontroller。goorderentity。goorderrepo。goregionregioncontroller。goregionentity。goregionrepo。gouserusercontroller。gouserentity。gouserrepo。go
　　这是如何在不妥协的情况下在松散耦合和高内聚之间找到平衡。
　　第一个选项适用于非常小范的项目，其中类型很少，处理程序很多，像ToDo应用程序，演示，单一职责命令行工具这样的幼稚项目适合这种情况，因为凝聚力不会受到太大影响，因为有每个包中的东西很少。
　　现第二个适用于其他一切：
　　如果一旦您在这些目录中拥有大量相同命名的。go文件，那么寻找单一类型的实现和跟踪代码将变得非常笨拙。
　　两打目录和几个文件比几个文件夹更容易推理，每个文件夹中有两打文件，每个文件夹都命名相同。
　　这就是为什么我从不选择第一种方法，因为随着熵的增加，它几乎总是蜕变为第二种方法，而且当我可以从那里开始的时候，重新构建所有的东西是浪费时间的。
　　按团队划分
　　下面是我们团队的标准布局，我们有一个工具可以保证这一点。
　　我们的布局是这样的：etcpetapi。yamlinternalconfigconfig。gohandlercatcreatehandler。godogcreatehandler。goroutes。gologiccatcreatelogic。godogcreatelogic。gosvcservicecontext。gotypestypes。gopet。goetc是yaml配置文件的文件夹config包含配置的Go定义handler包含路由的HTTP处理程序logic包含每个处理程序的biz逻辑svc是从外部传入处理程序的服务上下文，例如数据库实例。types是定义请求和响应类型的文件夹
　　为什么我把逻辑文件夹和handler处理程序分开，是因为我希望我们的团队尽可能少地把HTTP请求的信息传递给逻辑处理函数。
　　另外，所有文件夹的布局是由goctl从下面的API定义文件中生成的，命令是goctlapigoapidemo。apistylegozerodir。type（CatCreateRequest｛Namestringpath：name｝CatCreateResponse｛Messagestringjson：message｝）type（DogCreateRequest｛Namestringpath：name｝DogCreateResponse｛Messagestringjson：message｝）server（prefix：v1）servicepetapi｛handlerCatCreateHandlerpostpetscats：name（CatCreateRequest）returns（CatCreateResponse）handlerDogCreateHandlerpostpetsdogs：name（DogCreateRequest）returns（DogCreateResponse）｝
　　前缀：v1将v1添加到服务中的所有路由，它是可选的。
　　对于单体服务，我们会在内部下添加模型文件夹，用于数据访问代码。
　　另外，goctl支持自定义生成行为的选项，比如命名风格、将请求分组到不同的包中，甚至将处理程序和逻辑分别压缩到一个文件中。
　　安装：goinstallgithub。comzeromicrogozerotoolsgoctllatest
　　六边形架构
　　对于微型服务来说，拥有如下软件包：cmdservicenamemockserviceinternalentitieserrorsrepositoriesdatabasefxratesproviderserverhttpgrpcusecasescmd持有启动你的服务的方法httpgrpc等在server目录下你的服务的进入点usecases领域业务逻辑层mysqlfirestone其他一些api在repositories目录下来自外部的任何数据entities创建并通过各层传递的模型errors全局错误，使错误检查更容易。
　　优点。没有循环的依赖关系非常清楚地将逻辑分离出来只要满足预期的接口，就可以互相替换层（你的老板决定明天要支持http？没问题！）。更容易测试更容易用gomock来模拟接口更容易调试（根据我的经验，更少的面条，更清晰的责任）。
　　缺点。一些重复的代码转换为实体有时是件麻烦的事
　　原文：按技术职责还是按领域职责来构建代码？Reddit