Facets and Domain Modeling

Eric Evans has performed a tremendous service by writing a book extolling the virtues of domain models in general and Domain-Driven Design¹ in particular. Eric writes in an engaging and respectful style that is well conceived, filled with learning and insight, and that is practical and easy to read. The book is a must read for anyone serious about serving their business well through custom software development.

Facets

Facets is GemStone Systems Java Object Database and is the offspring, so to speak, of GemStone-S, their Smalltalk Object Database. As with its Smalltalk older brother, Facets' strength is its enterprise class server-side virtual machines that are the execution engines for this unique object database. Facets stores and works directly with Java byte code, plain old Java objects (POJO). Facets transparently manages the persistence of any Java object that is reachable from a root object bound into Facets' root context, which is managed through JNDI. While Facets has some shortcomings, partially enumerated below, it is second to none in its ability to fully and transparently enable the storage of and highly-concurrent access to a domain model.

As a result, in order to understand the value of Facets one needs first to understand the value of the domain model, which can be discussed from a number of perspectives.

What is a Domain Model?

A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert's head; it is a rigorously organized and selective abstraction of that knowledge. (Evans, 3)

Well said. Perhaps the only notion not explicitly stated in this short characterization of a domain model, but said elsewhere in the book, is the fact that the abstraction is subject to change as the expert grows and learns and as business changes. The proverbial moving target.

Guided by the goals and objectives of the business in general and the project in particular, the domain model is the implementation of that portion of the abstraction, selectively and iteratively developed, that serves the purpose at hand. In effect a reflection of the real world to achieve some business goal. If that sounds difficult to nail down then you're on the right track, which brings us to a significant hurdle to domain modeling: not many developers are given incentive to nor are they inclined to tackle building domain models.

Domain work is messy and demands a lot of complicated new knowledge that doesn't seem to add to a computer scientist's capabilities. .. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. (Evans, 4)

In addition to the predisposition and incentive problem, most IT organizations are not structured to allow for incremental development of a domain model. Although it is a subject beyond the scope of this paper, suffice to say that Agile Management and Agile Development can go a long way toward addressing some of these structural problems, allowing for the deep and real-time information-exchange between business and IT necessary to fully and adequately inform and develop the domain model.

Domain Model Evolution

When we set out to write software, we never know enough. (Evans, 15)

In my view, as software developers, communication is the most difficult thing that we do. Unfortunately, much of the industry relies on its practitioners to say things once, in written form, and to say them perfectly so that all can understand exactly what is being asked for. And then relies on the consumer of such written information to drink it all in and understand it perfectly. Very little opportunity is given to: 1) allowing the business to learn and change its mind (although it does anyway), or 2) dialog between the business and IT within a very specific context to discover the nuance required to implement the domain correctly.

Assuming ongoing proximity to domain expertise, there are two challenges to modeling the domain well: 1) learning the domain in general, or at least the portion that is candidate for implementing as software, and 2) keeping up with change in the business.

Highly productive teams grow their knowledge consciously, practicing continuous learning. (Evans, 16)

Knowledge crunching is an exploration, and you can't know where you will end up. (Evans, 21)

Recognize that a change in the Ubiquitous Language is a change to the model. (Evans, 27)

That we do not understand the domain completely is not to say that we do not know it sufficiently to deploy useful software to production as directed and decided by the business. In fact it is quite to the contrary. We should build and deploy what we know and trust that we can incorporate what we need when we need it through iterative refinement and refactoring of the existing system.

Power of a Domain Model

If sophisticated domain experts don't understand the model, there is something wrong with the model. (Evans, 33)

Domain-Driven Design goes to great lengths to show the value of a single view of the domain shared by technical and non-technical participants and described through Explanatory Models. The resulting degree of common understanding through thoughtful and rigorous use of language has a high leverage value to the business. When our language is shared and directly reflected in the software then discussing and making changes becomes much easier.

Process Implications

Doing domain modeling well touches every aspect of software development, especially overall process and methodology. For the reasons alluded to in our domain model discussion, domain-driven design is not well served by any flavor of Waterfall methodology nor by the manufacturing metaphor so heavily used in our industry as they both lead to overemphasis on the division of labor. In addition, the resulting hand offs are counterproductive to an information and communication intensive craft. Our need to crunch knowledge is greatly hampered by waterfall-induced cycles of hand-off-and-translate.

Translation blunts communication and makes knowledge crunching anemic. (Evans, 25)

Evans goes to great lengths to bring process together so as to bring people together. Proximity between those who know and those who need to know should be very close. Again beyond scope but worth reiterating, Agile Management and Development can go a long way toward enabling this.

If the managers perceive analysis to be a separate process, the development team may not be given adequate access to domain experts. (Evans, 48)

The importance and difficulty of domain modeling carries with it significant implications to the overall practice of software development.

Development becomes an iterative process of refining the model, the design, and the code as a single activity. (Evans, 50)

Domain-Driven Design, a Compelling Practice

Evans goes on to discuss the building blocks for domain-driven design, providing very practical and concrete advice for isolating, expressing, encapsulating, and accessing domain models, some of which I will cover in a separate article.

The practice of domain-driven design is compelling on many levels. Its salutary effect on language used in building software has great potential for productivity gains. Its single-model focus can result in more agile systems to serve the agile business. Its attention to detail and nuance bodes well for system integrity and six-sigma level quality assurance. Its participative nature between business and IT holds great promise for Alignment with and Transparency to the business. In the end, a dedicated effort to use domain-driven design can result in much more efficient use of scarce corporate resource, such as money, time and intellectual capital.

Facets' Role

If one buys that domain-driven design is a compelling practice and sees the value of the domain model then it is possible to begin to see the value of a software platform that is is predicated upon domain models and that can greatly facilitate the practice of domain-driven design by making the implementation of domain models easy and without artificial or technology-imposed concession.

The goal of domain-driven design is to create better software by focusing on a model of the domain rather than the technology. (Evans, 148)

Eric gives us many concepts, patterns and constructs that allow us to isolate the domain model and treat it separate from the underlying platforms and technology, so long as the implementation language enables the domain-driven design paradigm. He identifies object-oriented languages, such as Java, and logic languages, such as Prolog, as good fits, where procedural languages such as C would be a poor fit.

Tool and Paradigm Fit

Object-oriented design, the paradigm that currently dominates the majority of ambitious projects, is the approach used primarily in this book. (Evans, 52)

Facets is a pure-Java platform and an excellent fit for domain-driven design. Any POJO-based domain model can be directly stored in Facets just as any 1.4 compliant Java byte code can be executed in a Facets VM. Domain-Driven Design provides some rigor and focus about how to approach, refine, package, implement, deploy and refactor domain models. All of Domain-Driven Design can be implemented without concession in Facets. This is not true when you mix object-oriented and relational paradigms.

No Modeling Concessions

Same Fabric

Facets is one of the few database technologies that does not impose any artificial constraints on domain-driven design.

When the database schema is being created specifically as a store for the objects, it is worth accepting some model limitations in order to keep the mapping very simple... Mapping tools are sophisticated enough to bridge significant differences. The trouble is, multiple overlapping models are just too complicated. Many of the same arguments presented for model-driven design, avoiding separate analysis and design models, apply to this mismatch. (Evans, 159)

Once again Evans proves to be very pragmatic and forthright about the human side of software development. In this case, he is recognizing the power of the tools that have emerged to bridge the gap between object-oriented languages and relational databases. From a technical standpoint these are extraordinarily impressive, especially if one considers the caching capabilities demonstrated by some. In the end, however, it is important to note the difficulty of a two-model approach to software development. No matter how talented the IT staff, significant time is required to keep these models in sync. Unfortunately, all too often, development teams choose to not try to keep the models in sync and simply rely on the bridging technology, thereby compromising the potential life span of the system once the mapping becomes too complicated or too fragile.

Facets is 100 percent Java. For those implementing in Java then Facets is of the same fabric as the domain model.

Domain Encapsulation and Access Efficiency

There is a mindset common to many that work with object-oriented and relational technology together that Evans identifies and characterizes very well.

It becomes natural to think of the objects as containers for the data that the queries provide, and the whole design shifts toward a data-processing style. The details of the technology vary but the problem remains that the client is dealing with technology, rather than model concepts. (Evans, 149)

Unfortunately, this often results in a data-object, rather than domain-objects, that contain just enough relational data to answer the question that is asked, ideally through a service, thereby greatly affecting the shape and content of objects that would otherwise be domain-objects and causing business-logic to be sprinkled throughout the architecture (my observation is that once the business-logic escapes from domain-objects it can and often does end up anywhere). It does not take much by way of extrapolation to understand the cost of maintaining and enhancing such an implementation.

Through the magic of the Facets VM, when you get a hold of a root-entity you have the entire domain model and only the domain model. Referencing contained entities (domain-objects) causes the objects to be faulted in seamlessly and transparently. When any of these objects are modified or when the object graph is added to then it only takes a simple commit for these changes to be persisted. No domain encapsulation violating is necessary or desirable.

We need no query access for persistent objects that are more convenient to find by traversal. (Evans, 149)

Evans spends much time helping us to give our domain models well defined boundaries, in what he calls Aggregates (I'll come back to this in a moment because it is one of the significant contributions of Domain-Driven Design). The implication for doing so and accessing entities only through the root-entity is a difficult one for those who have to reconstitute their objects from a relational store. It takes quite a commitment to stick with the paradigm of bringing back enough of the domain model to instantiate an entire tree to get at a leaf-end object from the root-entity, or even to impose the discipline of giving this illusion through Evans' Repository pattern. This discord is what leads to the earlier mentioned practice of creating data-objects and processing them per discrete service call.

This is an easy problem to solve in Facets. Root-entities are the only objects bound into collections known to the root context (a JNDI tree). Once the Repository has a hold of the root-entity then traversal for a contained entity is the nature of using Facets.

Fixing Facets Shortcomings

There seems to be a tendency among object modelers to have a single, monolithic object models as opposed to well defined, atomic and well partitioned object models. Historically, Facets has suffered from implementations that reflect this reality and, amazingly, that provide a single access point (portal if you will) to get at the entire tree. Until Domain-Driven Design, it was a better practice to provide multiple access points into these very large models by identifying key parts of the domain that need to be directly accessed. In my view, Evans greatest single contribution is to provide us with a formal language for and approach to distilling our domain models into well partitioned Aggregates.

Transformation

Transformation is a difficult problem in any database technology. It is not the schema (DDL or class shape changes) that are difficult but rather the logic often required to populate new or changed fields. In any modest sized system this can take days or weeks of development to prepare transformation scripts and hours to run at time of conversion, irrespective of whether were speaking of relational or object databases. For early versions of Facets, known as GS-J, this was compounded by a single threaded process for performing transformation which has since been greatly sped up.

Evans notion of Aggregates has a salutary affect on Facets from at least one perspective: transformation is better contained physically because it is better contained logically. The component-based nature of Aggregates lends itself to more focused and well contained development that results in potentially deep and valuable changes in small parts of the overall system that can be rolled out in intervals. This translates into smaller portions of the domain needing to be transformed at any one point in time. By the way, it should have the same beneficial effect on relational transformation if its practitioners are faithful practicing what is in Domain-Driven Design.

Administration

Facets administration has many of the same considerations as the Java VM in general. For example, just as the VM must garbage collect so must Facets except that Facets must account for the entire repository and for objects that live beyond the process in which they were created. For better or worse, there are many variables available to tune Facets and it depends at least in part on the structure, use and size of the overall repository. Often times, these tuning variables go unused until a customer experiences some difficulty. It is my conjecture that by partitioning the domain models into Aggregates, Facets we will end up with less deviation between repositories thereby allowing for better baseline configurations and easier administration due to: 1) having greatly reduced the number of relationships to manage between objects, 2) more efficient access to objects, 3) better shared page cache usage where the probability of related objects being in close proximity would be much higher, and 4) simply better logical understanding of performance and sizing due to the encapsulation provided through Aggregates.

Conclusion

Since I am 1000 words past my intended limit I will stop here and summarize. To understand the value of Facets it is first necessary to understand the value of a domain model. Domain-Driven Design is a compelling approach to domain modeling with many beneficial effects to building software for business. Facets is a platform that is predicated on the existence of a domain model and whose 22 year heritage makes it very friendly to the implementation and refinement of domain models. Facets does have shortcomings that Domain-Driven Design concepts do a good job of mitigating.