Angular applications that are architected will have components that are not only reusable but have well-defined boundaries. This is to say that they have a separation of concerns. Each component does one thing and does it well. The components should be abstracted away from one another, and they should not know about each other's details (that is, implementation). The one thing that they should know about each other is how to communicate with each other. This is accomplished via their public interfaces, and we'll look at this shortly.

For now, all you need to know is that when you plan your application's components, you should list their responsibilities. That is, write down what they will be doing. Astute readers will probably see the connection between the use case diagrams and the lists of component responsibilities, since components are how users will be interacting with the application.