Object-relational mappers furnish a mapping layer between object-oriented code and relational databases. ORMs such as NHibernate and Entity Framework support lazy loaded associations which allow the loading of specific subsets of an object graph from an underlying relational store. This is beneficial because an object model can construct an object graph which is unfeasible to contain in main memory in its entirety. Lazy loading can prevent unnecessary data from being loaded and as such it is often presented as a performance optimization technique. This technique however incurs several drawbacks and is limited in its scalability. One drawback is that classes are static declarations and object associations will be accessible regardless of whether they are lazy loaded or eager loaded. As a result, it becomes more difficult to understand code because it isn’t immediately certain whether navigating an association will result in a database call behind the scenes. Moreover, care must be taken to ensure that an ORM session is available lest we run into the dreaded LazyInitializationException. Given that lazy loading is typically implemented using the proxy pattern, data access implementation details inevitably and invisibly leak into the rest of the application. In sense these characteristics can be regarded as a violation of the principle of least astonishment.

Abstraction is a fundamental operation of the mind. (According to Wikipedia, abstraction is believed to have developed between 50,000 and 100,000 years ago). In philosophy, Locke views abstraction as the act of separating from ideas all other ideas which accompany them in their real existence. In computer science, Dijkstra views abstraction as the creation of new semantic levels. Locke’s definition is structural in that abstraction tends to remove aspects of an idea, especially aspects that make an idea concrete. Dijkstra’s definition emphasizes the goal of abstraction. After all, it doesn’t seem sufficient for abstraction to be the separation of arbitrary aspects from ideas. Instead, it is the chiseling away of specific characteristics that bring value to abstraction. Characteristics are removed yielding an idea that isolates interesting components of a less abstract idea. One advantage of this process is that of generality - propositions believed to be true about an abstract notion should also hold for the more specific notion. Another advantage is that of encapsulation - references can be made to abstractions instead of concretions thereby simplifying the problem space by disregarding unimportant details. Joel Spolsky, with the Law of Leaky Abstractions, observes that “All non-trivial abstractions, to some degree, are leaky”. This observation alludes to the dark side of abstraction - the side where abstraction is misguided, shortsighted and of course leaky. The law stems from the software engineering perspective, however, it is applicable to all manifestations of abstraction. In software engineering in particular, the act of abstraction is pervasive - function declarations, class declarations, assignment of variables are all acts of abstraction. As such, software engineering also provides ample opportunity for leaky and needless abstractions.

Validation is a broad subject because it is prevalent throughout all areas of an application. Validation is difficult to implement in practice because it must be implemented throughout all areas of an application, typically employing different methods for each area. In a general sense, validation is a mechanism for ensuring operations result in a valid states. The ambiguity in that statement must not be overlooked because it illustrates several important characteristics of validation. One characteristic is context - the context under which validation is invoked. Context is critical because validation in one context may not be applicable in another context. Another corollary is the open-endedness of what is regarded as valid. Validity may be a trivial statement such as “The string representing a customer’s name must not be null” or it may be a complex sequence of CycL assertions. This post addresses validation as manifest in DDD-based enterprise applications. Validation, in this post, is distinct from a related discipline of correctness in theoretical computer science as researched by the likes of Edsger Dijkstra.

Domain-Driven Design espouses the repository pattern as a way to persist and reconstitute domain objects from a persistent store such as a database. Repositories are typically used to provide access to aggregate roots, entities and less frequently to value objects. Eric Evans attributes another potential responsibility to a repository in the blue book:

UPDATE: Vaughn Vernon provided some very valuable insight into the differences between application services and domain services as well as emphasizing the Hexagonal architectural style.

The term service is overloaded and its meaning takes on different shades depending on the context. As a result, there is a cloud of confusion surrounding the notion of services as one tries to distinguish between application services, domain services, infrastructural services, SOA services, etc. In all these cases the term “service” is valid, however the roles are different and can span all layers of an application.