Domain Model

The Heart Of Software

Noti has been designed and continues to evolve based on domain-driven design principles. After performing some knowledge crunching, the model revealed the existence of targets, tags, methods, and notifications (more specifically, target notifications and tag notifications).

Target

A target is the recipient of a notification. Each target can be reached using one or more of its methods. Targets can receive a notification that is explicitly tailored to them, or a notification that is directed at one or more tags that the target is associated with.

Each target has a name, typically assigned an easily recognizeable and meaningful identifier by the client that created it. A single target must have at least one method, and there must not be two methods associated to the target with the same value. Targets are usually tagged in order to construct meaningful "groups" of targets. Notifications can then be sent to one or more tags

Target
- name:string - methods:Set<Method> - tags:Set<Tag>
+ tag() + getTags() + getMethods() + addMethod() + getName()

Tag

Tag
- name:string
+ getName()

Method

Method
- type:MethodType - value:string
+ getType() + getValue()

Notification

Notification
- message:string - status:NotificationStatus - method:Method - sentAt:Date - sendAt:Date
+ send() + getMessage() + getStatus() + getMethod() + setStatus() + getSendAt() + setSendAt()

Invariants

• Cannot be put into a CANCELLED state once it has reached a SENT state.
• Cannot resend notification.

TagNotification

TagNotification
- tags:Set<Tag>
+ send() + getTags()

Invariants

• Cannot be associated with two tags that have same value.

TargetNotification

TargetNotification
- tags:Set<Target>
+ send() + getTargets()

Invariants

• Cannot be associated with two targets that have the same identity.
• Cannot be sent to targets that do not have a method matching one of the notification's methods.

Entities

• Notification (therefore, descendants TagNotification and TargetNotification as well)
• Target

The Notification class (as well as it's descendants) is considered an entity because we need to be able to identify that two Notification instances are the same, regardless if the properties of those instances match. For example, a Notification progresses through various statuses, such as SENT or CANCELLED, that indicate the state of that Notification. It is vital that when presented two Notification instances with different status values (such as when a notification is being updated to a CANCELLED status, for example), that we know that it dealing with the same notification.

Target has been chosen as an entity as well, because we want to track the state of that target over time. A target may start with a single method such as SMS, but may later add a method such as email. A target may start off as being tagged as NEW_CUSTOMER, but later have that tag removed. Through all of the changes to the attributes of a target it is imperative that we are able to identify that those changes have occurred to a single target.

Value Objects

• Method
• Tag

Both Method and Tag are considered to be value objects, because they are defined by their attribute values. Two instances of the Method class are functionally equivalent if they share the same attribute values. Same goes for Tag. There is no need to keep track of any state or changes to a Tag or Method. Instead, any difference in the properties between two instances will be considered a different "value" altogether.

Aggregate Roots

• Notification
• Target

Currently, there have been two aggregates identified, one being rooted with Notification, the other with Target.

Factories

Repositories

Services