DDD泛在语言UL

领域驱动设计DDD有两个难题：给事物命名，以及在另一个有界上下文中再次命名它们

以下是我的规则引擎几个基本要求： 使用某种表达语言来编写规则， 应该可以将规则存储在数据库中， 规则需要优先级，因此只有最好的才能被解雇， 也应该可以触发所有匹配规则， 规则应该针对一个输入进行评估，该输入可以是像树这样的对象，包含规则需要评估

微服务是开发软件的最具可扩展性的方式。但是你需要一个好的设计，让开发团队自主工作和部署，而不会互相干扰，否则你将失去可扩展性的好处。领域驱动开发允许我们通过将更大的系统分解为独立的单元、了解每个单元的职责并确定它们之间的关系来规划微服务架构。在本文中，我们将学习领域驱动设计的基础知识

最近一篇论文发表在《自然》杂志上：提出了一种研究人类是如何进行计划、规划或建模的新方法。 例如在国际象棋中

CQL（clinical-quality-language）是一种高级别的医疗保健领域特定语言，专注于临床质量，并针对医疗保健质量测量和决策支持工件创作。CQL 已经成熟为一个能够表示以临床为中心的逻辑的灵活规范，并被用于从队列定义和质量测量到临床决策和认知支持、可计算指南和公共卫生

业务治理需要一条自动化治理工具的途径，用于解释和消除自然语言和定义的歧义。翻译成决策表或翻译成其他一些外来形式（例如编程语言）并不是一个有效的解决方案。一个至少不以某种受控或结构化形式支持自然语言的规则平台总是会发现自己与业务治理的核心需求和实践不一致。

任何 Java 企业级应用程序都可以分为三个部分 - UI - 用户界面（前端） 服务层又连接到数据库 业务层 在 Drools 出现之前，我们还没有处理业务逻辑的标准方法。Drools 是一个业务逻辑集成平台 (BLiP)<

Picnic公司的独特的服务有赖于两个团队：Customer Success 和 Marketing 团队，但是与客户群规模相比，这两个团队相对较小，因此人少办事多，那么自动化就是应对这一挑战的答案，而这正是规则引擎发挥作用的地方。在这篇博文中，我们将深入探讨业务流程自动化领域，特别

恰逢马斯克收购推特之际，马斯克表示将公开推特的算法，最近推特新增又删除了一个名为“算法”却无代码的GitHub存储库，一些人认为这是在与马斯克开玩笑，更专业的观点如下：一些 Reddit 用户将此视为一条神秘信息，认为推特Twitter其实根本没有算法；而其他人则认为 Twitter

本文讨论了支持product、customer、sale和location 概念的记录类型。这些记录的名称因组织所处的业务线而异，特别是组织的销售流程。 与产品有关的记录在本系列文章中，产品的概念在第三部分

业务领域有三种数据模型： 1. 概念模型 2. 规范化的核心概念模型 3. 逻辑数据模型 对应于数据库中的模型： 1.物理模型 2. 物理业务数据模型 3. 规范化的业务数据模型 4. 逻辑数据模型 业务领域

每家公司都有定义其程序、政策和业务功能的规则和流程。这些规则支配着决策管理： 开发处理客户信用申请的应用程序 贷款申请和处理， 注册后会发生什么， 当客户被允许增加其透支额度时 这些决策背后是定义流程和条件的业务规则。这些规则

我们目前还没有一种用于DI（Design Intent设计意图的简称，意图包括架构，业务规则）的语言。当DI被嵌入到了代码中的会出现病症：如果你需要重构，那么很可能代码还没有被切分为DI和实现两个部分。 过多的细节走向了DI的对立面。 

如果不对数据进行分组，则会在您不注意时，根据数据得出的结论可能会随时逆转，这被称为#辛普森悖论，它在理论上和实践中都对数据分析造成了严重破坏。让我们看一个现实生活中的例子。假设我们用 A 和 B 治疗肾结石。在 350 名患者中，A 对 273 例有效，B 在 289 例中有效。（<

借助全渠道规则引擎，将实时交互情境化并提供无缝的受众旅程，下面是一个演示场景： 杰克收到一封来自银行的电子邮件，向他提供个人贷款。 他点击查看报价后导航到汽车贷款部分。他开始填写申请表的过程。 他关闭了网站，但没有完成表格。 两天后，我发现自己在一个自

我们在临床实践中所做的一切都需要数据。基本上我们需要三件事的数据：确定患者的当前状态，即诊断。确定患者的预期状态，即预测。以及我们是否可以通过医疗干预改变患者的预期状态。导致观察到的状态，即结果。这些基本之间的关系描述如