JMatter is a framework for building software applications that embrace
the notion of domain-driven design: that the essence of a software
application is the translation of domain knowledge into code; the
modeling of the domain into a set of entities with interrelationships.
Briefly: many of of those things that Eric Evans discusses in his
book Domain-Driven Design [5]. But this framework does more
than embrace these ideas: it is a vehicle for implementing domain-driven
applications today. The JMatter codebase constitutes a robust and
generic implementation of all of the layers of a software application
to support a given domain. This is an extremely agile proposition.
In this short book alone, we managed to develop four fully-featured
and distinct software applications.
How such agility is achieved can be described succinctly as follows:
By implementing all application services (search, forms, authorization,
persistence, ui, etc..) generically, in a fashion decoupled from any
one specific domain model, these implementations are free to be reused
across domains.
The consequences of this reuse are dramatic:
- large time savings
- an application's codebase shrinks dramatically and becomes manageable
- there's a clean separation between application development and infrastructure
development
- consistent, high-quality applications
This model of development puts into question certain rules about software
development that up until now we'd assumed to be a given, namely:
that the cost of making a change to a software system late in the
life of a software project is much higher; or conversely that it's
cheaper to implement changes early on, when less software has been
built upon requirements that may change.
The above rule inherently assumes that much of an application's codebase
is coupled to requirements, so that when the requirements change,
a lot of code will have to be thrown away and rewritten:
- GUI forms will have to be revised to reflect a new field
- There will undoubtedly be ripple effects to the database schema
- Queries will have to be revised to take a new field into account
- The authorization system will have to be updated because a new action
was introduced
And the list goes on. The entire application has to be retrofitted
to take the change into account.
In JMatter the repercussions are kept to a bare minimum: the database
schema derives from the domain model, as does the user interface,
and the authorization system, and the search system, and so on.. All
reflect the domain model.
22.1 Looking Forward
What technologies to base a project on is always a difficult choice,
and a moving target. For example, Java is used in many environments
today, but we see a desire to move to languages such as Scala, Groovy,
and Ruby. On the other hand, new languages may have less mature code
libraries, and involve a certain risk.
JMatter strikes a great balance in its choice of technologies. It's
a reality today; it's built upon a mature platform, a stable set of
libraries, Hibernate being one example.
Looking forward, we will likely be exploring new languages for the
JVM such as Scala, Groovy, and JRuby.
These languages will bring about tangible benefits:
- Traits (also known as mixins) are a powerful and missing feature (from
Java) that will provide more flexibility in modeling. Internally,
in terms of JMatter's own implementation, it will help streamline
the implementation even further.
- The functional programming traits of some of these languages promise
to bring about improvements in performance via lazy loading, and in
thread safety via immutability.
- Powerful metaobject programming facilities, and the very designs of
these languages promise to provide the necessary tools to evolve how
domains are specified into a full-fledged domain-specific language.
As one small, concrete example, the Scala language defines the notion
of a value object via the built-in primitive val. Much redundancy
in specifying a domain model can be done away with. You are likely
to start seeing JMatter move in the direction of such languages in
the coming years.