我正在开发与多个Charging Station连接的电动汽车充电站管理系统,我陷入了僵局。在这个领域中,我为Charging Station提供了一个聚合,其中包括Charging Station的内部状态(不管它是否连接,它的连接器的内部状态)。
它有一个UnlockConnector方法,为了准确地尊重它的名称(而不是贫血),它将请求发送到相应的Charging Station,因为知道Charging Station的连通性并向物理Charging Station发送请求是我领域的核心。
type Connector struct {
Status string
}
type ChargingStation struct {
Connected bool
Connectors []Connector
URL string
...
}
func (station *ChargingStation) UnlockConnector(connectorID int, stationClient service.StationClient) error {
if !station.Connected {
return errors.New("charging station is not connected")
}
connector := station.Connectors[connectorID]
if connector.Status != "Available" {
return errors.New("connector is not available to be unlocked")
}
err := stationClient.SendUnlockConnectorRequest(station.URL, connectorID)
if err != nil {
return errors.New("charging station rejected the request")
}
station.On(event.StationConnectorUnlocked{
ConnectorID: connectorID,
Timestamp: time.Now(),
})
return nil
}我想出了另一个表示Charging Session的聚合,即用户和Charging Station的Connector之间的交互。Charging Session的创建与Connector的状态完全耦合在一起,也就是说,如果Connector被用户解锁,则创建会话,如果Connector的能量流停止,Charging Session就结束了。
无论两者是如何耦合的,Charging Session实体似乎不属于Charging Station聚合,因为它没有回答主要的问题:当一个站点被删除时,它的Charging Session也应该被删除吗?)另外,当我要支付在这个会议中消耗的能量时,它与空间站的聚合上下文没有任何关系。
我想创建一个SessionCreator域服务,以确保当Charging Station的Connector被解锁时,还将创建一个Charging Session:
type SessionCreator interface {
CreateSession(station *station.Station, connectorID int, sessionID int) error
}
type sessionCreator struct {
stationClient StationClient
}
type (svc sessionCreator) CreateSession(station *station.Station, connectorID int, userID string, sessionID int) error {
err := station.UnlockConnector(connectorID, svc.stationClient)
if err != nil {
return err
}
session.Create(sessionID, station.ID, connectorID, userID)
return nil
}然而,它只是感觉有点奇怪,并且不完全满足其他不变量(当连接器的能量流停止时,它必须结束会话),我认为它还可以做一个监听StationConnectorUnlocked事件的事件侦听器,但是我不知道哪种方式是理想的。
发布于 2020-04-30 22:10:20
根据我从问题中所能理解的,我认为您的聚合Charging Station和Charging Session是正确的。您说它们都是耦合的,但在我看来,Charging Station不需要知道会话的存在,会话实际上也不需要知道任何关于站点内部的信息,所以对我的耦合程度很低。
关于在电台发生事件时如何创建和修改会话的问题,根据您的措辞,解决方案在我看来是很清楚的:
如果连接器已被用户解锁,则创建会话,如果连接器的能量流停止,则充电会话已结束。
突出显示的词是商业活动。你可以画得像:
我实现这一点的方式是使用pub/子系统,因此在状态更改之后聚合发布事件,订阅者触发用例,这些用例可能在聚合上执行操作,最终可能会发布一个事件。
这种方法的分布式特性使得跟踪整个系统上正在发生的事情变得更加困难,因为解锁连接器和创建会话不会在一个地方发生。它们很可能发生在系统的两个不同部分。好处是,随着时间的推移,涉众可以想出许多需要在连接器解锁时发生的事情,而且您只需要继续向现有事件添加订阅者。
https://stackoverflow.com/questions/61529751
复制相似问题