Project 7: Design a Marketing Automation System - Part 2
Our fourth diagram is going to be a deployment diagram. For this, we want to focus on how the APIs are going to be connected, because there are a lot of moving pieces in this system.
Guide Tasks
  • Read Tutorial
  • Watch Guide Video
Video locked
This video is viewable to users with a Bottega Bootcamp license
APPLY NOWLEARN MORE

Deployment Diagram Requirements

  • Load balancer
  • Multiple application servers
  • Database cluster
  • Email server
  • SMS Connector
  • SMS Provider
  • External CRM

We're modeling a system that plugs into tools like Salesforce and then lets you follow a lead as they're taken through the marketing journey. You'll have the ability to track what that data flow looks like with this diagram and see where the servers are positioned.

I included a load balancer again so that you can review how that can be diagrammed, but the big focus on this diagram is the API connectors. You'll need nodes to connect the system to various outside services, such as Salesforce or the SMS service. Feel free to get creative with how you organize these because this is a very complex system. You're going to have servers all over the place, advanced systems like load balancers, and even services you don't even own, which is a very common practice in modern development projects.

Our fifth diagram is a state machine diagram.

State Machine Diagram

  • Visitor
  • Prospect
  • Lead
  • Opportunity
  • Closed (Won)
  • Disqualified Prospect
  • Unsuccessful Lead
  • Lost Opportunity

The user's state is critical when it comes to modeling a system like this. We have to keep track of what type of user we're dealing with because that helps us decide what actions we're going to perform.

For example, a potential customer will start as a "Visitor". They can then become a "Prospect", "Lead", and "Opportunity". Ideally, from that state, they will be marked as "Closed (Won)", which means that they actually became a customer, but there are other possibilities. We also have to take into account whether they are even qualified to be a prospect. If a 12-year-old signed up for devCamp we wouldn't be able to enroll them as a student, so that would immediately disqualify them. Maybe they tell a marketing specialist that they're just not interested, which makes them an "Unsuccessful Lead". Lastly, we have a "Lost Opportunity", which is a situation where someone went all the way through, but at the very end, they decided they did not want to sign up.

Being able to capture each one of these states is vital because the state is going to determine how we're treating that customer at any point in time.

Last, but certainly not least, is the class diagram. The focus here is going to be on inheritance.

Class Diagram Requirements

  • User
    • MarketingRep
  • Report
  • Form
  • Journey
  • Reminder
  • Message
    • Email
    • SMS
    • ExternalChannel
  • Customer

Focus on how we can create a generic class, and how we can leverage subclasses to get more specific.

The Message class in particular can help us understand how to model inheritance because "Message" is something that's generic. No one's actually going to use a message. They're going to use one of the more specialized Message types, such as email, SMS, and external channels.

A simple way to tell if you're using inheritance right is if you would describe one class as a type of another class. For example, an email is a type of message, or marketing rep is a type of user.

Finally, remember that a customer is not a user. They do not interact with the system, so we need to keep track of them in a different way.