> 2021年05月13日信息消化 ### 每天学点Golang #### We wrote a book about building bussiness applications in Go 原文: [Show HN: We wrote a book about building business applications in Go](https://threedots.tech/go-with-the-domain/) 因此，我认为DDD基本上是迄今为止发现的开发优秀软件的最佳模式之一（与gangof4、SOLID等一起考虑）。围绕着它有很多杂乱无章的东西，顾问们为了得到聘用而想把它过度复杂化，但简单地说，它主要是关于概念边界的抽象化--在大多数大型项目中很难反对这一点。 也就是说，鉴于Go 1.x中的类型系统是如此（有意地）受限，谁能谈谈在Go 1.x中构建大型 "企业级 "应用程序的情况？虽然Go中的协议很好（Go提供的许多新鲜空气之一），但在没有泛型的情况下对数据结构进行操作似乎并不是一个好时机。大家是否通过将大多数看起来像泛型的操作做成稍微特殊的结构和一些接口组合来解决缺乏泛型的问题？ > So I think DDD is basically one of the best pattern that has ever been discovered for developing good software (thinking of it along with gangof4, SOLID, etc). There's a lot of cruft around it and consultants looking to over-complicate it for the sake of getting hired, but viewed simply it's mostly about abstraction at conceptual boundaries -- very hard to be against that on most large projects. > That said, can someone weigh in on how it is building large "enterprise-grade" applications in Go 1.x given how (purposefully) constrained the type system in Go is? While protocols in Go are great (one of the very many breaths of fresh air that Go provided), operations on data structures without generics does not seem like a good time. Does everyone get around the lack of generics by making most generic-looking operations slightly-specialized structs and some interface composition? 我认为你混淆了一些东西。[Go-kit](https://gokit.io/)与DDD相距甚远。它甚至在其网站上说 "专注于你的业务逻辑。"。这基本上是所有的东西，但不是领域代码。 对于CRUD-y应用程序，你通常根本不需要DDD模式，因为没有复杂的业务逻辑需要建模。 > 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. #### 关于CURD与DDD stackoverflow https://stackoverflow.com/questions/23970567/ddd-and-avoiding-crud A very important part of DDD is bounded contexts. DDD的一个非常重要的部分是有边界的上下文。 A bounded context is a delimited part of an application where terminology is consistent. DDD is very seldom the correct approach for an entire application. Therefore we usually divide an application in separate bounded contexts. Within each bounded context you can have a different pattern. Say CRUD for a BC that has very little domain complexity and DDD for an area with high complexity. 有界限的上下文是应用程序的一个限定部分，其中术语是一致的。对于整个应用，DDD很少是正确的方法。因此，我们通常将一个应用程序划分为独立的有界上下文。在每个有界的上下文中，你可以有不同的模式。例如，CRUD用于领域复杂度很低的BC，而DDD用于复杂度很高的领域。 CRUD is not to be avoided per sé. CRUD is to be avoided when there are complex business rules in play. DDD is to be avoided when you're providing forms over data with very little rules. CRUD本身是不应该被避免的。当有复杂的业务规则时，应避免使用CRUD。当你在规则很少的数据上提供表单时，应避免使用DDD。 So, it is possible to have an application with some parts doing simple CRUD and other parts with a richer domain model. 因此，我们有可能在一个应用程序中的某些部分做简单的CRUD，而其他部分则有更丰富的领域模型。 That's one part of the equation, to get back to your original question: 这就是等式的一部分，回到你最初的问题上。 *"before teachers can grade students, a SchoolYear has to be present or perhaps a GradingPeriod"* You imply here that creating a schoolyear is a CRUD operation, you're probably already thinking about `"INSERT INTO schoolyears ..."`. That is a possibility (and you could do it that way using bounded contexts, see above). Using CRUD for that part is OK, if there's not a lot of domain logic going on. "在教师给学生打分之前，必须要有一个SchoolYear或者GradingPeriod" 你在这里暗示，创建一个学年是一个CRUD操作，你可能已经在考虑 "INSERT INTO schoolyears ..."。这是一种可能性（而且你可以使用有界的上下文这样做，见上文）。如果没有太多的领域逻辑，使用CRUD来处理这部分是可以的。 However, you need to determine whether "inserting a new schoolyear" is not actually technical jargon for "opening a schoolyear". DDD emphasizes language. If you determine that opening a new schoolyear has a lot of rules attached and requires complex code, you should probably put it inside your domain. So if your domain experts keep telling you about how they "open a new schoolyear", then you should model that behavior in your domain. So instead of calling it "InsertNewSchoolYear", you should call your method "OpenNewSchoolYear". Whether that eventually does an insert in the DB is irrelevant, you want to capture that specific domain knowledge in your model. 然而，你需要确定 "插入一个新学年 "实际上不是 "打开一个学年 "的技术行话。DDD强调的是语言。如果你确定打开一个新学年有很多附加规则，需要复杂的代码，你可能应该把它放在你的领域里面。因此，如果你的领域专家一直告诉你他们如何 "打开一个新学年"，那么你就应该在你的领域中建立这个行为模型。所以你不应该叫它 "InsertNewSchoolYear"，而应该叫你的方法 "OpenNewSchoolYear"。最终是否在数据库中进行插入并不重要，你要在你的模型中捕获那个特定的领域知识。 ### 其他值得阅读 #### 让你在任何对话中占上风的强大技巧 原文: [A Powerful Trick That Gives You the Upper Hand in Any Conversation](https://medium.com/mind-cafe/a-powerful-trick-that-gives-you-the-upper-hand-in-any-conversation-eec2f4a3d27b) > Chinese negotiators use it to get what they want. ##### The Power of a Pause > “What do you think happens after we die, Keanu Reeves?” > > *He takes a long pause, and with an unnerving level of calm, says:* > > “I know that the ones who love us will miss us.” It’s an unusually profound answer for a chat show, which is often tailored toward unfunny jokes and scripted comedy sketches. Reeves didn’t feel rushed, despite the cameras and audience. Instead, he took time to answer such a serious question which enabled him to give a powerful, apt answer. It’s beautiful. ##### The Best Communication is When You Don’t Speak at All > “As soon as you need words there’s already a failure to understand each other so you’re repairing that failure by using words.” Unlike English and Dutch speakers, **the Japanese are happy with silences of 8.2 seconds**, according to a [study](https://commons.emich.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=1052&context=gabc) by Haru Yamada, a senior lecturer of linguistics. > “Chinese negotiators are very, very aware that Americans like to fill silences and they are trained to stay silent and impassive because that will make the Americans uncomfortable and possibly make concessions without the Chinese having to do anything.” > > "中国的谈判人员非常非常清楚，美国人喜欢填补沉默，他们被训练成保持沉默和无动于衷，因为这将使美国人感到不舒服，并可能在中国人不需要做任何事情的情况下做出让步。" While it may feel unnatural, staying silent can be incredibly beneficial. ### 一点收获 - Auth0 - DXを加速するシステム開発とID基盤 - アジリティ - セキュリティ - ユーザー体験（UX）  - CURL -X OPTIONSでOriginを指定して実行 - ```bash curl -H "Origin: http://example.com" \ -H "Access-Control-Request-Method: POST" \ -H "Access-Control-Request-Headers: X-Requested-With" \ -X OPTIONS \ -v "http://localhost/post" ``` - 自由的保证是什么?是对自己不再感到羞耻。--尼采 - 技术选型是跟着业务走，不是看哪种玩得花，你们要观察下很多业务做得很好得网站，界面和交互体验很差的，但是用户根本不在乎，因为它真的能解决问题