• 一切都是相关的 相对的 关键在于上下文context 矛盾？我们只注意矛与盾两个相对方，但是忽视了它们发生关系的上下文场景。 阴阳？只注意阴和阳，忽视了阴阳相生的上下文。 一分为二，或者矛盾的统一体 等概念都让我们忽视了背后的上下文 [img]
  • 混合推理，也称为神经符号人工智能，是一种将机器学习和符号推理相结合的人工智能，旨在实现互补，弥补前者的不足，如可靠性、可重复性和透明度的不足。 该项目的主要思想是通过简单但引人注目的例子展示混合推理，特别是如何将 LLM 与规则引擎相结合，允许在不同的业务领域中实现聊天机器人，这些聊天机器人既方便用
  • 格雷戈尔·霍普在本文讨论了8本被视为软件架构师必读的经典书籍。 以下是所提及的关键书籍的摘要： 1、维特鲁威（公元前 20 年）的《建筑学》： 虽然与软件架构没有直接关系，但这部古代文献被提及，具有历史背景和个人丰富意义。 2、《1975 年 icon
  • Mark Seemann这篇博客文章反对使用自然键作为数据库表中的主键，而是建议始终使用合成（人工）键。 什么是自然键 自然键（也称为业务键或领域键 ）是数据库中一种唯一键，由存在并在数据库外部世界（即业务领域或论域）中使用的属性组成。[3]在关系数据模型中，自然键是超键，因此是关系中所有属性的 功 icon
  • 原文：蛋白酥皮哲学：讨论了形而上学的领域建模，强调了将代码实体与领域模型实体对齐的重要性。作者主张模型和代码库之间一一对应，这样在模型发生变化时可以更轻松地维护和更新。 icon
  • DDD中的错误抽象比其他设计方法具有更大的破坏性影响。这篇文章分享了 DDD 中代价最高的设计错误；导致单一和紧密耦合系统盛行的一个常见错误。 背景 企业中存在很多臃肿而脆弱的客户应用程序接口，而针对这种脆弱性提出的解决方案，最终会在客户应用程序接口不可避免地变得过于繁琐时，将其拆分成更小的、目的明 icon
  • ASOS人工智能团队是一个由机器学习工程师和科学家、数据科学家和产品经理组成的跨职能团队，利用机器学习来改善客户体验、提高零售效率并推动增长。 banq注：在讨论[url= icon
  • 对于复杂性，人们总是想消灭它（有为），而不是去消化接受它（无为），其实，无为胜有为。 1、传统教条 以下是人们面对复杂性实施的教条方法： #敏捷 听上去很好，但是可能回避复杂性，因为敏捷这个词语有回避障碍的意思，如果陷入复杂性困境，就无法敏捷行动了 敏捷只适合小公司，那么大公司开始采 icon
  • 在传统的 Java 编程中，数据传输对象(DTO) 长期以来一直是处理应用程序各层之间数据交换的首选解决方案。虽然 DTO 达到了其目的，但它们通常会导致代码臃肿、维护开销增加并降低可读性。这就是 DTO-Free Java 的用武之地，彻底改变我们在 Java 应用程序中处理数据的方式。 通过采用 icon
  • 左边：以领域模型为划分 右边：以分层架构为划分依据 icon
  • 在多个服务之间共享代码可能会成为项目团队争论的话题。服务涵括范围越大，关于如何在不同服务之间共享功能的争论就越激烈。 [list] [*]一方面，开发人员认为 DRY（不要重复自己）是正确的做法。 [*]另一方则是 "无共享 "理念的支持者。 [/list] 通常情况下，任何一方都无法 icon
  • 您所有表/实体上是否都有“created_at”和“last_update_at”字段？为什么？这是好还是坏做法？ [b]网友：[/b] 1、大多数模型相关表都有created_at、updated_at，如果我使用软删除，则deleted_at 2、只要有一个审计表来记录所有内容，了解谁改变了什么 icon
  • 当谈到 Go中结构体值时，人们纠结：通过指针传递这些值还是只是复制值？ 由于指针会带来一些开销，因此人们自然的反应是不惜一切代价避免使用它们，并尽可能传递结构值复制副本。 而我通常选择使用指针结构的两个原因是标识性和一致性。 对于我的项目，我宁愿使用 语义： 我会查看结构类型应该表示什么，并预先 icon
  • 知识图成为现代软件工程实践的基石。 知识图是一个巨大的信息网络，其中元素和想法相互链接以显示它们在现实世界中的关系。这超出了仅存储信息的数据库的范围。知识图谱还存储信息之间的联系。 这使得知识图谱在各个领域都非常有用。这里有一些例子： 搜索引擎：搜索引擎使用知识图来理解搜索词与现实世界实体之间的 icon
  • 事件风暴是一种动态研讨会方法，深入研究领域和需求发现。获得的见解非常宝贵，有助于设计与业务边界紧密结合的软件，从而简化维护。 事件风暴提供三种不同的研讨会类型 - 大局观、流程级别和设计级别。 1、研讨会准备 邀请谁？ icon
  • 在事件风暴上，实现下面几个步骤： 我们首先进行了一次混沌探索，从每个人那里收集了相关的领域事件。 之后，我们通过整理事件、删除重复事件和微调事件来组织混乱。 会议结束时，我们将事件按时间顺序排列。 我们还指出了一个热点，强调了我们不确定的事情。 此外，我们还使用了一些黄色便签来记录我们不想忘记的关键 icon
  • 一不小心，你可能会被事件风暴冲昏头脑，犯下这些新手错误！ 以下是具有技术背景的人特别容易犯的两个反模式错误！ 不幸的是，这些错误可能会让一个成功的 "事件风暴 "研讨会变成一个失败的计划，让参与者尝到苦头。 幸运的是，这两种反模式很容易避免！因此，请记住它们，一切都会顺利！ icon
  • 领域驱动设计（“DDD”）是一种专注于系统领域而不是技术的软件设计方法。重点是构建共享的心理模型并以尽可能简单的方式在代码中表示该领域模型。数据库存储、框架等技术细节被认为是设计的次要方面。该模块将重点关注 DDD 和一般设计以及相关主题，例如文档和软件架构的某些方面。本课程使用基本的函数式编程概念 icon