Application design is perhaps one of the most widely covered topics in application development, particularly in the Java world, which seems both to benefit and suffer from an overabundance of books on architecture issues and design patterns. In this chapter, we are not going to rehash all of the information contained in these books, nor are we attempting to provide an exhaustive guide to application design. Although we hate to admit it, you won't find any frighteningly clever and original solutions in this chapter. What you will find, however, is a discussion of tried and tested OOP practices that result in applications which have clearly defined component responsibilities and which are also easy to test and maintain. This chapter looks at the impact Spring has on application design, paying particular attention to patterns and practices that you will find easy to apply when you are building your application with Spring. Much of this chapter focuses on the design decisions we made when building the SpringBlog application, and we use that application as the basis for our examples and discussions.
This chapter is not just about application design. We also focus on how we used many of the Spring technologies covered so far to implement the data access and business logic tiers of the SpringBlog application.
Specifically, in this chapter we look at the following:
Interface-driven design: Interface-driven design is a traditional OOP best practice. When you use interface-driven design, the main components of your application are defined in terms of interfaces rather than concrete classes. Java offers first-class support for this kind of design with its notion of interfaces separate from classes. In this section of the chapter, we discuss interface-driven design in general terms and why you should use it in your applications.
Building a Domain Object Model: In this section of the chapter, we look at the notion of a Domain Object Model (DOM), a collection of objects that provides an abstract model of the data in an application's problem domain. By creating a DOM for your application, you are creating a set of objects for modeling application data and behavior that matches some abstract idea of your problem domain. Using a DOM provides a great number of benefits for your application, not the least of which is reducing the level of impedance between an application's code and the real-world problems it is attempting to solve.
The Data Access Tier: Most applications nowadays need to access some kind of persistent data store, typically a relational database. Chapters 8 through 10 discussed Spring's support for a variety of different data access methods. In this section of the chapter, we look at the design issues related to building a Data Access Tier to service the rest of your application.
Building the Business Tier: An application's Business Tier is where all of the business logic that makes up the application is encapsulated. In this section, we look at how the Business Tier interacts with the Domain Object Model and Data Access Tier to provide a unified interface to access application functionality. We also look at the business requirements of the SpringBlog application and how this translates into an interface design and an implementation of that interface. This section also touches briefly on the topic of transactions, looking at how the design of your Business Tier can affect the choices available when you are specifying transaction settings.
Data validation in Spring: An important part of any application's logic is data validation. You should definitely consider data validation part of an application's business logic, although the rendering of validation errors is outside the scope of the Business Tier. Spring provides a validation framework that accurately reflects this. In this section, we also cover how the data validation rules for SpringBlog are defined using the Spring validation framework. Chapter 17 looks at how this validation logic is employed by the Spring web framework.
You should note that this chapter does not cover design or implementation of the application's Web Tier; that is covered in greater detail in Chapters 19.