Now this is going to be a relatively straightforward package diagram. The most important component here is I want to show how to visualize communicating with outside services. So as you can see we have our frame right here called package marketing automation. And then inside of it we have a number of packages we have journey's, insights, channels and then inside the channels we have app drivers and then we have nested components here where we have a slack package and then a hipchat package and then we have this aggregate type of association description. And the reason for this is because technically slack and hipchat are going to be outside services and they need to implement whatever we have here for our outside app drivers. So what I typically like to do in a situation here where I'm going to be passing messages to outside services such as slack or Hipchat or Twitter or Facebook. Each one of those systems has their own unique API.

If I were to simply build one module that was supposed to communicate with each one of those that would start to lead into some very messy code. What I try to do instead is I create one connector that can manage all of the data communication and then other elements so other packages such as slack and Hipchat and this instance can then implement what we have with app drivers and so I can communicate with any one of the outside services but the journeys and all of the other parts of the application they won't even realize that theyre doing it so it doesnt care if its sending a message to slack or SMS or any other type of communication channel.

All it knows is that it's communicating with this app driver module so you can send a message, a user, anything like that. And then this driver can be in charge of handling all the API communication. Communicating in a way that is secure getting responses back and it can manage all of that inside of the package and that's really one of the most important parts I wanted you to get out of this entire solution is how you can wrap that up.

Now as far as looking at some of these dependencies journeys is the main functionality of the application. If you went through the solution for the activity and the use case diagram journeys really is the focal point. This is what happens when a user signs up and starts going through the entire marketing automation system. Now through that journey also needs to be able to communicate and have an association with insights. So in order for the journey to function properly it has to know when the last communication with a user occurred. It needs to know if a user opened up an email or responded to a text message. All of that data is going to be stored inside of insight. So in that case journeys does have a dependency on insights. Now journeys also has a dependency on channels because a journey is all about sending out communication. It doesnt manage the actual sending of it but it is in charge of managing everything that leads up until that point.

So a journey isn't really able to do anything if it can't communicate. So in that case a channel is definitely a dependency for journeys. And so this is a pretty high-level diagram but it should give a good idea on how you could wrap an entire system, entire marketing system up and how you can illustrate what the dependencies are and also how you can nest packages inside of other packages.