One of the great features in frameworks like Ruby on Rails is that they enable you to focus on implementing business logic. No need to set up anything (other than a database connection). No need to be concerned with technical stuff: if you need to persist or query things, or mail something for example, the framework can shield you from the lower level and provides you with an easy to use DSL.
Something similar can be achieved with Domain-Driven Design. I first came in contact with this concept in 2004. The client I was working for had hired Rob Vens as architect, not just for the (humongous) application they wanted to build, but also for an architecture that would last many more applications to come. Vens introduced them to his idea of DDD, and the client’s architecture was based upon it. It wasn’t until much later that I picked up Evans’ book on DDD and found out that both visions may be compatible, but focus on quite different areas of the theory. In short, Vens says:
- A domain should be ever-expanding, it knows no boundaries. Changes in requirements should lead to additions, not changes to the domain.
- A domain should always be live, always active.
- A domain should be able to execute business processes dynamically. As business processes change continually, a dynamic domain model is a better way to support them than a process model, which is static.
- A domain should have no infrastructural dependencies (e.g. persistence, authentication, logging). Instead, it is surrounded by adapters listening to events happening in the domain. Adapters handle these events by calling on external services. As these services are independent of the domain, they can be made generic and therefore reusable between domains.
- A domain should be modelled using the time-inversion pattern and the active-passive pattern. That is: start modelling behaviour at the end of the process (in the spirit of demand chain management), and model passive objects in the real world as active ones in the domain model.
And there’s much more to it, but you’d better visit Vens’ own site (although it is a bit fragmentary, unfortunately).
Like I said, these are ideas that you won’t immediately find in Evans’ Domain-driven Design: Tackling Complexity in the Heart of Software. Evans emphasizes the importance of a shared, ubiquitous language and a shared domain model. Most of the book covers his ideas on modelling the domain. He says relatively little about the actual architecture of a Domain-Driven application. What he does say forms the linking pin with Vens: there should be one application layer for the domain, that doesn’t contain anything having to do with infrastructure.
However great their ideas are, neither Vens nor Evans offer a practical implementation. What I’d really like is a framework ready to use, ready to start building a DDD application with. A framework that allows me to start implementing the domain model without worrying about technical stuff–because the technical stuff is all outside the domain in generic, reusable services. But also a framework that can be used pragmatically, together with other standard frameworks for building Java applications (e.g. Hibernate/JPA, JSF, EJB3 or Spring).
Bastion wants to be that framework.
2008-11-01. 2 responses.