DDD泛在语言UL

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

程序员职业生涯两次落泪时刻：1、大学毕业后

EventStorming是一个系列的研讨会，基于在一个大的模型表面（通常是一个纸卷）上用便条实现集体讲故事。Big Picture大图 是最大的规模的味道：它可以涉及相当多的人（25-30是典型的数字），并引导你探索整个业务线和结束。迭代法让参与者通过 "事件 "可视化其组

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

架构图是软件设计的基础，也是软件开发沟通和协作的基础工具。在 Spotify，我们拥有一个极其复杂的网络，由数百个团队拥有的数千个相互关联的软件系统组成，因此有一种简单的方法来可视化这些连接是必不可少的。 虽然在一张大图中捕获我们所有的软件在技术上

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

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

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

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

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

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

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

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

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

当提到 "公共基础设施 "时，人们通常会想到道路、桥梁、铁路、水坝、发电厂、城市照明。这些都是公共资助/拥有/管理的推动者，它们使更多的老百姓能够做生意，并满足基本需求。公共基础设施有时是免费的，但并不总是如此（你支付电费和过路费；当然有人会正确地指出，没有什么是免费的，因为我们通过税收支付

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