Following the event storming session, the subsequent bounded contexts have been identified:
Users Management: it is responsible for managing the users’ lifecycle, from registration to deletion and the management of their profile information along with the authentication and authorization.
Groups Management: it is responsible for managing the group lifecycle, from creation to deletion, and the management of the group members.
Location Tracking: it is responsible for managing the location tracking of the users, including the sharing of the location with group members, the reception of location updates, the sending of SOS alerts and the management of their paths.
Notifications: it is responsible for managing the notifications, including the push notifications to the users’ devices.
Chat: it is responsible for managing the chat between the users and the group members.
In the following sections, we will provide a detailed view of each bounded context, including its Ubiquitous Language, the Commands and the Events guiding the interactions between the different contexts.
These can be categorized as Driving or Driven Events: the former are the events triggered by the user’s actions and that drives an application use case, while the latter are the events that are triggered by the system as a reaction to a use case or a system state change.
Moreover we distinguish between Commands and Events to highlight the difference between a request to perform an action (Command) and the notification of something meaningful that has happened (Event).
A specific point on a geographical plane, represented by coordinates that indicates where something / someone is located.
Position
Address
A human-readable description of a location, usually including the street name, the city, the country, and the postal code along with the related location.
ETA
Estimated Time of Arrival, the time at which a user is expected to reach a certain destination.
Route
A set of positions that can be interpolated forming a path between two geographical positions.
Path
Tracking
Represent the user route information at a certain point in time.
State
State of a user at a certain time, the values that it could assume are: online, offline, SOS, Routing, Warning.
Session
An aggregation of the user’s tracking information, the state and last location of a user in a certain period of time.
The boundary of each bounded context delineates the scope of the context: models in different bounded context can be evolved and implemented independently, but they need to be integrated to provide a coherent service to the users.
DDD provides a set of patterns for defining relationship and integrations between bounded contexts to be reified in the so-called Context Map, a visual representation of the system bounded contexts and the relationships between them.
The following diagram shows the context map of the PositionPal system:
The shared kernel collects the shared entities and domain logic that are in common between the bounded contexts.
As per best practices, the overlapping module will be limited as much as possible to avoid coupling between the contexts and exposing only the part of the model that, otherwise, would be duplicated in all the contexts.
The conformist pattern applies to users and groups management context: the downstream context (Group Management) conform to the upstream context (Users Management) model to simplify the integration and avoid the complexity of translation between bounded contexts. Although this approach may constrain the downstream team’s design flexibility, it significantly simplifies integration.
Since the upstream context (Users Management) has more influence in this relationship, conforming to its model facilitates clearer communication and reduces integration overhead.