This post originated from an RSS feed registered with Java Buzz by Simon Brown. Original Post: Domain-driven design Feed Title: Simon Brown's weblog Feed URL: http://www.simongbrown.com/blog/feed.xml?flavor=rss20&category=java Feed Description: My thoughts on Java, software development and technology. Latest Java Buzz Posts Latest Java Buzz Posts by Simon Brown Latest Posts From Simon Brown's weblog

Yesterdays GeekSpeek saw a guest appearance from Martin Fowler and the group had an interesting chat about software development and Martin's experiences. During the discussion, Martin told us that he's recently written the foreword for a new book called Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans). In summary, it's a book about some of the patterns and principles that can be employed to really get to grips with and model the domain in which you are operating.

One of the most important parts of software development is understanding the domain and, regardless of whether you're using XP or RUP, building a domain model that represents the business can be very, very useful. Not only does it help in understanding the business, but it also helps you identify abstractions and elements of reuse. With the introduction of service-based architectures such as web services and, to a degree, J2EE, many people often forget about the importance of building a domain model, instead choosing to look at the system from the perspective of the services that it provides and model it accordingly.

Domain-driven design picks up on traditional OO techniques such as encapsulation and high cohesion to ensure that the responsibilities of your domain model are dispersed appropriately. I think what's going to be interesting is to figure out just how this maps onto some of these service based technologies. As an example, how many J2EE applications that use EJB have you seen that place business functionality next to the data in entity beans? Probably very few. I'm not saying that either way is wrong, but it does come back to an old argument about how to build J2EE systems using traditional OO techniques, and that J2EE systems are generally not truely OO because the data and behaviour are split between session and entity beans. Are we placing too much responsibility in session beans? Should they simply be service-based facades that map onto a true OO model? Some interesting questions and I'm looking forward to reading the book for some inspiration.