Motown offers a Core component that allows so called add-ons to communicate with it using commands and events. The hexagonal architecture that is used in the design of Motown prescribes developing the core of your application without a dependency on your User Interface (UI), database, or other inputs and outputs. This separation between inputs, outputs and the behavior or logic of your application allows for a composable system, which allows extension from third party add-ons.
CORE
The CORE is the center of the back office system Motown. The Core contains a representation of the charge points that the system is connected with. The CORE receives data in the form of commands, processes the data and transforms the data into an event. All events that are processed are stored in the eventstore database. This database is very valuable for future event mining. Most back office systems nowadays only store the current status of the system in the database. The eventstore enables us to gather valuable information for analysis.
COMMAND & EVENT BUS
The commands and events that are sent respectively to and by the Core are routed on a roundabout, the Core API. The Core API can also be called the Command & Event buses. The Core API has several functions; First, all commands and events that can be used by add-ons to send to the Core are listed in the Core API. Secondly, it routes the commands from the add-ons to the Core and delivers the events that are produced by the Core to the add-ons. Events are only delivered when an add-on is authorized to receive it. Therefore it can be seen as a roundabout on which all command and event packages are transferred and delivered, only to the exits that have the right subscription.
ADD-ONS
What would the Core be without having command senders or having receivers for events? The add-ons add functionalities to the total back office system Motown. The functionalities of the add-ons are widely spread and each user or partner of a Motown user can design functionalities to the system in the form of add-ons. One of the add-ons that has already been developed is OCPP 1.5. This add-on delivers the functionality of translating all data from OCPP 1.5 programmed charging points to the Motown Core. Other add-on functionality examples are:
- Authorization: the authorization of charging events is done with the use of the authorization add-on that checks the databases of (for example) Hubject, CIR and a Local party.
- VAS: a Value Added Services add-on can be used by third parties to ‘add value’ by using information about the charging station(s) in the Motown system. Via the VAS interface they can obtain information about the location, type and status of charging stations. The VAS interface also implements a push-mechanism. External parties can subscribe to get updates about the status of charging stations.
- Smart Charging Protocol: a smart charging protocol makes charging decisions when limited power is available. The data that is needed for the decision-making is retrieved with the use of the Motown Core and the demands from the protocol (commands) are converted to events that are sent to connected charge points by the Core.
Any other functionality can be added to a Motown system with the use of add-ons when desired. The most valuable thing of a widespread implementation of Motown is the compatibility of all add-ons. Any functionality can be implemented to all Motown systems in operation without custom-made modifications as long as it is compatible with the Motown Core.
The principle of CQRS (Command Query Responsibility Segregation)is used for the design of Motown. This principle uses separate query and command objects to retrieve and modify data respectively. The separate commands and events that are sent to and by the Core have been explained earlier. Another representation of Motown gives a good demonstration of the effect of CQRS and can be of additional help for the full understanding of Motown.
The representation on the left shows the Command & Event buses that are used for the transport of commands and events to and from the Core. Secondly, the main difference between the Core and all add-ons is well displayed in this picture. The arrows show the direction in which the packages of commands and events are transported. The stream entering the Core is contrary to the direction of the stream entering the add-ons. The Core is the only part of the system where commands are processed to events; all domain logic is situated in the Core.
Did you miss a more technical explanation of Motown? All technical information can be found on the Motown GitHub.