小编Ant*_*s S的帖子

我试图找到一种简单的方法来回滚到我的 firebase 函数（谷歌云函数）的先前版本，以防此 firebase 函数的新版本对已部署的系统造成问题。

我部署函数的方式是通过 firebase cli（firebase deploy --only 函数）而不是 gcloud cli。

有没有简单的方法可以回滚到该函数的先前版本？

我正在尝试使用 firebase 函数环境的functions.config() 变量，以便能够根据该变量是否设置为 true/false 来打开/关闭日志。我已经创建了它，但似乎基于以下链接（https://firebase.google.com/docs/functions/config-env#additional_environment_commands）中的信息，只有重新部署该函数才能更改它，使用 firebasefunctions:config:set 命令后，首先更改环境变量。

不过，似乎可以通过使用 gcloud 函数命令来部署函数（gcloud 部署而不是 firebase 部署）以及 --set-env-vars 命令（以及访问 env. 变量的不同语法）来实现。然后，只需导航到 GCP 控制台上的特定功能，然后转到“编辑”->“更多”并更改底部的环境变量，即可轻松更改该环境变量，只需更改变量的值即可。来源： https:
//cloud.google.com/functions/docs/env-var

所以我的问题如下：是否有类似的方法可以更改 firebasefunctions.config() 变量，而无需从 cli 重新部署该函数？

我想知道如果域事件不是聚合状态更改的自然结果，如何实现它（在 DDD 中）。

我借用这篇文章的例子。

因此，假设我们需要一个像：TemperatureWasMeasured这样的事件，它可能是我们所做的某些建模的产物（例如在事件风暴会话中）。

此事件感觉像是某些读取操作的产物，而不是某些聚合的实际状态更改。

所以问题是： 这个事件在哪里以及如何有意义地被发射？。

我们可以创建一个实体或聚合，它可以有一个状态来计算读取次数，以便作为状态更改发出。但这真的有必要吗？

在现有的资源中，“领域事件”的定义似乎没有提到状态变化，而只是在领域中发生了一些事情。

那么测量的动作（在非量子力学环境中）被认为是一个域事件，就像TemperatureWasMeasured事件一样？

如果有人能澄清这些问题那就太好了，因为似乎没有明确的答案。

我们创建了 .yaml 文件来在 Kubernetes 集群中部署 osrm/osrm-backend ( https://hub.docker.com/r/osrm/osrm-backend/tags )。

我们首先在节点卷中下载 pbf 文件，然后为服务创建必要的文件，最后服务启动。

您可能会在下面找到 yaml 文件：

apiVersion: v1
kind: Service
metadata:
  name: osrm-albania
  labels:
    app: osrm-albania
spec:
  ports:
  - port: 5000
    targetPort: 5000
    name: http
  selector:
    app: osrm-albania
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: osrm-albania
spec:
  replicas: 1
  selector:
    matchLabels:
     app: osrm-albania
  template:
    metadata:
      labels:
        app: osrm-albania
    spec:
      containers:
      - name: osrm-albania
        image: osrm/osrm-backend:latest
        command: ["/bin/sh", "-c"]
        args: ["osrm-extract -p /opt/car.lua /data/albania-latest.osm.pbf && osrm-partition /data/albania-latest.osrm && osrm-customize /data/albania-latest.osrm …

我想澄清一下在实现 DDD（领域驱动设计）的 EDA 系统（具有事件驱动架构的系统）中实现不同类型事件的方式。假设我们没有使用事件溯源。

更具体地说，阅读相关文章后，似乎有 3 种事件：

• 事件通知：这种事件似乎没有携带太多细节，它只是通知已经发生的事件，提供一种查询更多信息的方式。

"type": "paycheck-generated",
"event-id": "537ec7c2-d1a1-2005-8654-96aee1116b72", 
"delivery-id": "05011927-a328-4860-a106-737b2929db4e", 
"timestamp": 1615726445,
"payload": {
"employee-id": "456123",
"link": "/paychecks/456123/2021/01" }
}

• 事件携带的状态转移（ECST）：该事件似乎有两种风格，要么具有某些已更改信息的增量，要么包含资源的所有相关信息（快照）。

{
"type": "customer-updated",
"event-id": "6b7ce6c6-8587-4e4f-924a-cec028000ce6", 
"customer-id": "01b18d56-b79a-4873-ac99-3d9f767dbe61", 
"timestamp": 1615728520,
"payload": {
"first-name": "Carolyn", 
"last-name": "Hayes",
"phone": "555-1022",
"status": "follow-up-set", 
"follow-up-date": "2021/05/08", 
"birthday": "1982/04/05", 
"version": 7
 } 
}

{
"type": "customer-updated",
"event-id": "6b7ce6c6-8587-4e4f-924a-cec028000ce6", 
"customer-id": "01b18d56-b79a-4873-ac99-3d9f767dbe61", 
"timestamp": 1615728520,
"payload": {
"status": "follow-up-set", 
"follow-up-date": "2021/05/10", 
"version": 8
} 
}

• 领域事件：此事件位于其他两个事件之间，它比事件通知具有更多信息，但此信息与特定域更相关。

上面的每个示例都来自 Khononov 的书（学习领域驱动设计：调整软件架构和业务策略）

说了前面的陈述，我想澄清以下问题：

(1)与其他有界上下文通信时，事件携带状态转移 …