The Heart of Software

The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose. When the domain is complex, this is a difficult task, calling for the concentrated effort of talented and skilled people. Developers have to steep themselves in the domain to build up knowledge of the business. They must hone their modeling skills and master domain design.

Yet these are not the priorities on most software projects. Most talented developers do not have much interest in learning about the specific domain in which they are working, much less making a major commitment to expand their domain-modeling skills. Technical people enjoy quantifiable problems that exercise their technical skills. 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 frame-works, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.

In a TV talk show interview, comedian John Cleese told a story of an event during the filming of Monty Python and the Holy Grail. They had been shooting a particular scene over and over, but somehow it wasn't funny. Finally, he took a break and consulted with fellow comedian Michael Palin (the other actor in the scene), and they came up with a slight variation. They shot one more take, and it turned out funny, so they called it a day.

The next morning, Cleese was looking at the rough cut the film editor had put together of the previous day's work. Coming to the scene they had struggled with, Cleese found that it wasn't funny; one of the earlier takes had been used.

He asked the film editor why he hadn't used the last take, as directed. “Couldn't use it. Someone walked in-shot,” the editor replied. Cleese watched the scene again, and then again. Still he could see nothing wrong. Finally, the editor stopped the film and pointed out a coat sleeve that was visible for a moment at the edge of the picture.

Eric Evans - Domain-driven design: Tackling Complexity in the Heart of Software, 2003

Domain-Driven Design Community

Eric Evan's book is excellent and the "method", or at least, this way of thinking when given a design problem seems so natural. He's active in the Domain-Driven Community. First published in 2003 I think.

Eric does courses too. His courses are in NY but others are held in London

Eric's book is not in Kindle (so obviously not in iBooks). Domain-driven Design: Tackling Complexity in the Heart of Software

Good essay on the Domain Model (from 2006)

Essay: The Database Model is the Domain Model
By Frans Bouma

Preface

To work with data on a semantic basis, it's often useful to specify general definitions of the elements a given portion of logic will work with. For example, an order system works with, among other elements, Order elements. To be able to define how this logic works, a definition of the concept Order is practical: We will be able to describe the functionality of the system by specifying actions on Order elements and supply with that a definition of that element Order.

This Order element contains other elements (values like the OrderID and ShippingDate) and has a tight connection with another element, OrderRow, which in turn also contains other elements. You can even say that Order contains a set of OrderRow elements like it contains value elements. Is there a difference between the containment of the value OrderID and the containment of the set of OrderRow elements? The answer to this question is important for the way the concept of Order is implemented further when the order system is realized with program code.