One architecture pattern in particular shows up in nearly all applications, and that is the Layered architecture pattern.

The basics of this pattern is simple: most applications can be divided into a few categories:

Presentation and reception of data and commands to and from the user
Processing and Structuring of data and commands according to business rules
Execution of functions on the underlying system(s)
Storing Data

Many applications only store data and do not require the use of any low-level features. These are referred to as three tiered architectures, with the (perhaps more familiar) layers:

User Interface
Business Logic
Database

The idea of separating the applications functionality like this is separation of concerns.

When you are working with the user interface, you should only worry about how things should look like, and what commands should be available. At most, you have a few API endpoints on the layer beneath that you can use to pass data and commands on to the rest of the application (there are different principles for how to set up these endpoints that I discuss in a separate part of the course).

When you are programming the business logic, you should try to stay true to your domain model and model how the concepts interact in order to solve the business functions that you want (and as expressed in your use cases). You should not be at all concerned with how this is going to be presented to the end-users. Nor should you worry about how this is going to be stored.

The storage or database layer, finally. Here, you should only worry about how data should best be structured and stored in order to mimic how your domain model's data is structured and stored, and how to maintain integrity of your data (e.g. ensure that required links between objects are enforced so that you can not add data where those links are not properly set up).

If you have done things correctly, you now have an application with a set of well defined API endpoints, and you can access these endpoints either through a graphical user interface, a web server, a test framework, or a command-line interface. Likewise, you can replace your storage layer from one working with files to a full-fledged database without impacting any other parts of your application.

When you continue down the UML rabbit hole, this is an important feature of your design. All design starts from the point where a use case hits those API endpoints. And no object oriented design tries to also serve as an SQL schema for your database.