User interfaces: the enemy of Domain Driven Design

I’m passionate about Domain Driven Design (DDD).  Like many experienced object modellers, I was practicing this long before Eric Evans coined that specific term, though I have sinced learned some useful  specific patterns from his book. To me, DDD is about two things: focussing on the business functionality rather than on the technical implementation; and focussing on building a good model of the business domain rather than  just on the specific immediate requirements.  Like many others Read more »

Naked Objects and AOP – Part 2

Last month I wrote about the potential synergy between Naked Objects and AOP.  Since then I’ve conducted my first crude experiments with Aspect and the AJDT plug-in for Eclipse.  (I found the latter remarkably straightforward to install and use). Read more »

Lego, DSLs and Naked Objects

I consider myself to be something of an expert on Lego. In 1984 I wrote a book about robotics, which included instructions for building a number of quite sophisticated robots using Lego Technic. The book never sold well, and is now long out of print - but it did make my (substantial) Lego purchases tax deductable! Lego has oft been used as a metaphor for componentised software. I think it’s a poor metaphor, except insofar as it exposes the woolly thinking that surrounds the idea of software componentisation generally. A componentised system is one in which it is possible to replace a component with another implementation that conforms to the same specification: thereby not only giving you the choice of alternative suppliers, but also to encourage innovation. Sound and video systems, desktop PCs, and bicycles are examples Read more »

Comparing Naked Objects with Rails or Grails

In the course of presenting Naked Objects to a new community this week, I was asked how it compared to the Ruby on Rails and/or Grails frameworks  -  a question that comes up quite frequently.

Naked Objects is similar to Ruby on Rails and Grails in the following ways:

  • All three frameworks demonstrate a very high commitment to the principle of Don’t Repeat Yourself (DRY), specifically by deriving the presentation and/or the persistence layers from the domain model.
  • All three frameworks favour convention over configuration as a programming model.
  • All three frameworks can be used to deliver finished applications, but may also used to build prototypes of systems that will eventually be delivered on a different platform.

But there are also some profound differences Read more »

« Previous PageNext Page »