Because of the relative sophistication available when using sqlite3, our application software must become more properly layered. Generally, we'll look at software architectures with the following layers:

• The presentation layer: This is a top-level user interface, either a web presentation or a desktop GUI.
• The application layer: This is the internal service or controllers that make the application work. This could be called the processing model, and is different from the logical data model.
• The business layer or the problem domain model layer: These are the objects that define the business domain or the problem space. This is sometimes called the logical data model. We looked at how we might model these objects using a microblog blog and post example.
• Infrastructure: This often includes several layers, as well as other cross-cutting concerns, such as logging, security, and network access.
• The data access layer: These are protocols or methods to access the data objects. It is often an ORM layer. We've looked at SQLAlchemy. There are numerous other choices for this.
• The persistence layer: This is the physical data model as seen in file storage. The sqlite3 module implements persistence. When using an ORM layer such as SQLAlchemy, we only reference SQLite when creating an engine.

When looking at sqlite3 in this chapter and shelve in Chapter 11, Storing and Retrieving Objects via Shelve, it becomes clear that mastering object-oriented programming involves some higher-level design patterns. We can't simply design classes in isolation—we need to look at how classes are going to be organized into larger structures.