Two aggregates, or one but with multiple views

[henk...@gmail.com]

I am developing Electric Vehicle Charging Station Management System, which is connected to several Charging Stations, and I am in an impasse. In this domain, I've come up with an aggregate for the Charging Station, which includes the internal state of the Charging Station(whether it is network-connected, the internal state of its Connectors - plugs that charge the vehicle).

It has a UnlockConnector method, for which, to accurately respect its name(and not be anemic) it sends the request to the respective Charging Station(as it is central to my domain to know of the Charging Station's connectivity, and to send requests to the physical Charging Station) which allows a user to plug the connector and charge its vehicle.

Another thing that is central to my domain is the concept of a "Charging Session", the interaction between a User and a Charging Station's Connector. The creation of a Charging Session is entirely coupled with the Connector's state, i.e. if the Connector has been unlocked by a user, a session was created; if the Connector was plugged in the vehicle the Charging Session started consuming energy; if the Connector's energy flow has stopped, the Charging Session has ended. And almost everything that can happen on a session is derived from the station's connector's state.

That's why I don't know how to model the Charging Session, I know I need to query it, I need to know how many sessions have been made in a month, etc. So I think it would be ok to handle the session entirely on the Read Side:

• StationConnectorUnlocked -> Create a Charging Session and update the Station's Connector's state(to "charging"), in a view database;
• StationConnectorStoppedCharging -> Update the Charging Session(to "finished") and update the Station's Connector's state(to "available"), in a view database;
  

However it feels odd that this is not an aggregate on its own, because the Charging Session entity doesn't seem to belong to the Charging Station Aggregate, as it doesn't respond to the primary question: when a Station is deleted, should its Charging Sessions be deleted as well? No they shouldn't.

I was thinking also to simply listen events from the Station and emit command to the Session Aggregate:

• StationConnectorUnlocked -> CreateSessionCommand -> SessionCreated (which in turn would update the read-site)
• StationConnectorStoppedCharging -> FinishSessionCommand -> SessionFinished (which in turn would update the read-site)

However, there would almost be no validation in the session aggregate, because the only "mastermind" in determining the connector's state is the "Station", so if the station said that the connector has stopped charging, necessarily the session finished(i.e. it would not be acceptable to have an "available" connector with an ongoing charging session, and vice-versa).

Other things that I think about the session that justify it having an aggregate on its own are:

• Non-station related events: payment-related, sometimes we deem necessary to correct a session's information(if the station incorrectly informed them, and we have another source to correct that information)

[Ben Kloosterman]

At a glance  stationconnector is not really an aggregate as i dont see it needing data options. Id avoid the abstract concept of a session  as these tend to be "sticky" "-)   Instead id use business events with an id eg chargingstated for station xyx   charing finished etc.

1)  stationconnector emits commands 
2)   stationconnector emits events and  some sort of Charging Aggregate which is probably a Saga.

Ben