Domain Object Model Summary
In this section, we looked at the DOM for the SpringBlog application, and we spent some time discussing
the basics of domain object modeling and implementation. There is no doubt that the scope of this topic
is much broader than what we have covered here. Indeed, a whole range of books is available that
discusses the topic in detail (one excellent book about this topic is Domain-Driven Design: Tackling
Complexity in the Heart of Software, Addison-Wesley Professional). We only scratched the surface here,
and we focused on why you want to build a DOM, what the focus is when building one, and some
general topics related to the SpringBlog application.
Although it is certainly possible to build applications without defining and building a DOM, it is our
experience that taking the time to do so pays off in reduced complexity, lower maintenance costs, and
fewer bugs.
Designing and Building the Data Access Layer
Having discussed the DOM, let's proceed to the layer that is dedicated to performing the interaction
between the database and transforming the retrieved data to the DOM for processing by the service layer.
No one will question the need for a data access layer, because data access logic is always complex
and performance-critical. For example, in some cases where the performance of data access is critical,
the data access layer should be capable of firing tuned native queries to the database to maximize the
performance on data retrieval. Moreover, issues such as concurrency control (e.g.,
optimistic/pessimistic locking), caching, data auditing, and security requirements should be addressed
by the data access layer.
Typically, when implementing the data access layer, the DAO Pattern is widely adopted in JEE
applications, in which the responsibility of the DAO is to encapsulate the underlying persistence
technologies (e.g., JDBC, Hibernate, etc.). However, because today the persistence frameworks have
become much more mature and the rise of adopting JPA and its EntityManager that already hides the
persistence provider from the developer, it is a common practice to eliminate the DAO layer. Instead, the
persistence provider Service Provider Interface (SPI) will be injected into the service layer directly when
retrieving data. Figure 12-3 shows a diagram that uses DAO. (For example, for JDBC, the access logic still
involves writing a lot of queries within the code, and for this case, it's still better to put that code in the
DAO class to hide the service layer from those SQL statements.) Figure 12-4 shows another diagram within
which the persistence providers (e.g., EntityManager in JPA, mapper interfaces in MyBatis) are injected
into the service layer directly.
Search WWH :
