• ifelse很重要，几乎是程序员编程核心，业务逻辑与规则也通过ifelse体现出来，语句简单但是背后文章很大，先看几则幽默图： 1. 也许默认使用return false可以节省一半代码，这幅漫画抱怨了if else的累赘冗长，希望精简它，但是从业务逻辑精简是根本，如果只是在程序员可见的编码范畴边界
  • 也许默认使用return false可以节省一半代码：
  • 过去这十年规则平台的机会不仅仅是变得更智能，虽然这当然很重要，而且还可以消除程序员的工作量。 但是存在三个挑战： [list] [*]问题 1.我们是否取得了重大进展？ [/list] 这个问题很简单——绝对！决策和 DMN 标准为行业做出了重大贡献。所以，我们可以继续前进。 [l icon
  • 系统中的信息是人们之间交流过程的一部分。思想在头脑中流动；沿途有翻译，从概念到自然语言到形式语言（机器系统中的构造），然后再返回。 — Bill Kent 从人们交流的语言中发现客观世界已经是一种默认方法，包括机器学习的NLP或大数据分析都是这种情况，领域建模也是这种情况，复杂性系统中的信息会透过人 icon
  • Apache Isis是基于业务领域驱动而自动生成SpringBoot界面的开源RAD工具： 生产力- 该应用程序主要是业务逻辑，消除了昂贵的 UI 代码。 发现——业务领域专家和技术人员可以携手合作，了解问题空间，然后了解解决方案空间。 易于使用- 业务用 icon
  • 微服务是从认知负载角度划分的，每个团队都是由人组成的，人都是认知能力限制或天花板的，这些决定了团队的认知能力大小，一个团队不可能建立或管理其认知能力之外的领域上下文知识，也就无法建立和管理相应的微服务，认知负载边界=微服务边界。 根据康威定理，组织架构决定了技术架构，那么就要逆康威定律，如果你想要一 icon
  • 当我还是一个年轻的程序员，刚刚开始进入企业软件这个可怕的世界时，一个年长的、更有经验的小伙子对我在软件中硬编码hardcode的做法提出了严厉的警告。"硬编码会在某些时候被改变，你肯定不想为了改变某个增值税税率值而重新编译和部署你的应用程序。” icon
  • 业务和IT分离的时代已经过去，问题空间和解决方案分离的时代已经过去： “请给我解决方案，而不是问题！” 我从业务和管理部门多次听到这句话。你也听说过，不是吗？ 我们程序员应该回喊“请给我呈现问题，而不是解决方案！”（你在教我做事吗？） 想象一下，你正在从事人力资源系统的工作：假期、合同，诸如此类的事 icon
  • 荷兰环境与规划法的完整修订版将于 2022 年 7 月在荷兰生效，数字化是这一新法案落地的一个关键方面。 数字化的一部分是创建一个规则驱动的门户，因此非常重视决策规则的治理。 本文解释了为什么要建立一个新的决策规则标准来支持治理。该标准的一个概念是用于决策规则管理的分层模型方法。尽管该方法旨在用 icon
  • 业务决策和规则的管理更普遍地称为业务知识管理（业务词汇、概念、决策、业务规则），这是业务架构和流程性能改进（BPI - 业务流程改进）中所有现有方法框架中缺失的组件之一。 [b]什么是业务知识管理？[/b] 业务知识管理学科与流程管理学科有很强的互补性；事实上，它们是同一枚硬币的两个面。前 icon
  • 核心子域图帮助您可视化架构中每个（子）域或业务能力的战略重要性，从而使您能够做出与业务模型一致的架构决策。 这种技术的真正力量在于它引发的对话，尤其是跨学科的对话。复杂性是工程师可以衡量的东西，而业务差异化是由产品经理或业务利益相关者提供的。 衡量复杂性的重要性 首先，衡量你的领域的复杂性和差异化是 icon
  • Stefan Hofer 不擅长画图，然而，他认为他可以通过讲述领域故事来积累领域知识。Stefan 在奥地利学习软件工程并获得计算机科学博士学位。自 2005 年以来，他一直在德国汉堡的 WPS – Workplace Solutions 工作。他的工作是帮助团队开发以正确方式完成正确工作的软件。 icon
  • Scott Wlaschin 是一名开发人员、架构师和作家。他是流行的 F# 网站 fsharpforfunandprofit.com 的作者，以及 Pragmatic Bookshelf 出版的《Domain Modeling Made Functional》一书的作者。Scott 以其对函数式编 icon
  • 决策表是业务逻辑建模的表格形式，表示所有可能的条件组合。特别是在复杂的系统中，当多个业务规则共享同一组属性时，可以使用决策表轻松映射所有场景。 决策表具有用于映射条件及其操作的列和行。因此，可以使用不同的条件和操作来构建每个业务规则，而不会丢失所有可能的组合。 为了进一步解释所有组合，让我们考虑一个 icon
  • 这篇文章将介绍一种使用DDD和Clean Architecture构建应用程序的观点性方法。 我所说的 "观点 "是指，我将论证解决应用程序设计和架构中几个众所周知的问题的特定方式。当然，这并不意味着这是实现这些问题的唯一正确方法。 然而，它是DDD和架构领域长期以来的研究过程和成果。 网上有许多关 icon
  • 我经常阅读有关领域驱动设计如何过于复杂或过度杀伤的评论。然后还有其他新的 DDD 想要应用它，尤其是技术模式，无处不在。所以问题是，你应该使用领域驱动设计吗？答案在中间的某个地方。 大型系统 首先，让我定义一些我将在这篇文章的其余部分中提到的内容。在谈论系统的设计时，我指的是一个足够大的系统，它会影 icon
  • 一项有关手工编程与领域特定建模在开发效率上比较研究： 基于云的企业应用程序开发，传统手动编程和DSL领域特定建模相差986%。自动生成代码能迅速地带来了投资回报。 icon
  • Vladik Khononov 是《学习领域驱动设计》一书的作者。在这一集中，我们深入讨论了领域驱动设计 (DDD) 和 Vlad，首先分享了为什么理解业务领域在软件工程中至关重要，以及 DDD 如何帮助在领域专家和软件工程师之间建立共同的理解。Vlad 随后解释了 DDD 中的两个重要设计，即战略 icon