离开Java/C#并不喜欢在Go中看到DDD

我注意到，在 Gophers 的小圈子里，他们离开 Java/C# 的动机是渴望一种更简单、更直接的编程方法，以避免与 DDD 和其他强调松散耦合的范式相关的复杂性和不可预测性。

他们表示，之所以转用 Go，是因为他们的编程理念是强内聚而非松耦合。

然而，作为一个缺乏经验的开发人员，我很难理解 Go 比 Java 和 C# 等其他 OOP 更好地实现强内聚力的地方和原因，会在 Java/C# 中很难实现。

因此，如果您是一位在设计理念中优先考虑强内聚而非松散耦合的开发人员，并且这促使您从 OOPs 转向 Go，那么我很想听听您的想法，看看 Go 在哪些方面做得很好，从而促使您转型。

##########################################################

Go 中的包是函数、类型、变量和常量等相关代码的集合。获得内聚力的方法之一就是将所有相关代码组织在一起。

在 Java 和 C# 中，模块边界与类型混为一谈。如果没有相关的类型（类class），就不可能有模块。

内聚是一个与所有程序员都息息相关的概念。它甚至与汇编程序员也息息相关。

我认为，在 20 世纪 90 年代和 2000 年代，我们都被面向对象编程的热潮所吸引。这并不是说面向对象编程不好，这只是对我们在 20 世纪 90 年代和 21 世纪的编程态度的一种评论，当时我们把"对象"当作一种无所不能的方式，包括定义模块边界，而这并不是对象所擅长的。

让程序员来决定模块（包）边界的位置是件好事。就是这样。在 Java 中，模块的边界就是类的边界，程序员在决定如何组织代码方面没有那么大的灵活性。

#################################################################

是的，我在一家咨询公司工作，所以在这个项目中又使用了 C#。在 Go 领域工作了 8 年之后，这感觉就像是一种折磨。

除非您真正勤奋使用 C#，否则项目组织可能会变得一团糟。

编译器错误和警告是晦涩难懂的。更糟糕的是控制器上的所有 .Net 装饰器和示例只显示了使其工作所需的一半。

而在 Go 中，发现错误要容易得多。

####################################################################
我在 Java 和 Go 两种语言上都有广泛的工作经验（作为专业工程师，我在这两种语言上都工作了 3 年以上），我实在无法理解这种推理。

Go 允许将函数放在模块的顶层，但这大致等同于在 Java 中定义静态类成员（静态函数或静态类）。调用端甚至使用了相同的点符号：Java 中的 UtilsClass.foo()，与 Go 中的 utils.Foo()。

Go 似乎并没有为你提供任何本质上不同的功能，只是语法不同而已。
换句话说，Java 略显啰嗦，每个 "模块 "都需要一个类包装。注意，你说的模块是什么意思也不清楚，因为它既可以指包，也可以指类。但 Go 和 Java 都支持多文件包。

我当然更喜欢 Go 组织模块的语法，但我不确定它是否真正触及了 OP 所问的核心问题？

说了这么多，我对 "OOP "和 "DDD "这样的术语很过敏，我发现它们大多是由 Bob Martin 叔叔这样过于教条的人强加给我们的。我认为这些分类在实践中毫无用处。

#####################################################################
DDD 是指具有尽可能强的内聚力，因此不可能出现意外情况。这通常需要具有大量验证的强类型。

#####################################################################

DDD 本质上并不是关于耦合或内聚。它是关于设计以领域为中心并明确建模的软件。它甚至不关心你使用 OOP 还是 FP。这只是一个想法：开发人员和领域专家应该一起探索问题领域并对其进行建模。
我知道，因为我见到埃里克·埃文斯时就问过他。
我还认为 Go 可以被认为是一种 OOP 语言，因为 OOP 不是关于类，而是关于消息传递。Go 提供了多态性。

########################################################################
我也和埃里克讨论过这个问题。
主要目标是建立我们试图解决的问题的模型，然后拥有与该模型实际匹配的代码。
在大多数组织中，这是一个沟通问题，坦率地说，组织的不同部分并不在同一页面上。这会导致软件解决方案不充分。

#########################################################################
我的理解是，如果没有“良好”的凝聚力，你就不可能拥有它。

############################################################################
java和C#中常用的很多原则在go中并没有广泛使用或非常严格。在大多数情况下，严格遵循 OOP 和 7 层 MVC 模式之类的事情是不必要的，并且会导致更多的复杂性和浪费时间。

##################################################################
代码结构遵循业务/问题领域是其核心。如果您的客户使用某个术语来表示某件事，您应该使用该术语而不是开发人员特定的术语。如果用户总是一起使用功能 A 和 B，那么它们的代码可能应该靠近在一起，等等。