Before I get into today’s topic, I’ll just have to point you to a review of the Apple iPad by a doctor. Main point: it fits in a regular white coat pocket. Very important.
In Sweden, we do have a problem, though, since doctors in general aren’t allowed old fashioned white coats, but go around dressed in the same pajamas everyone else has. The idea seems to be that doctors should be as indistinguishable from nurses and administrative staff as possible to keep the patients on their toes and make the doctors more amenable to accept lower salaries. So big pockets are out, here. But the iPad could change that (desperate hope). Wait… an idea is being born… an Apple branded white coat with an iPad pocket? An iCoat?
After this interruption, back to the regular programming. Last week I drew a diagram as part of the “domain analysis”, without explaining what that means. Sorry about that, I’ll explain it now. First, “domain analysis” is a process that produces, among other things, a “domain model”. I should actually have used the term “domain model” last week, it’s more correct.
A “domain model” describes the actual parts and interactions of the systems in reality, not in a software application. In my case, it describes the concepts that I as a doctor would use when seeing a patient. When you look at my diagram from last week, you’ll see “clinical guideline”, “issue”, “item”, and so on, which don’t really exist in reality, so it isn’t a pure domain model either. When drawing that diagram I did something impure, but very useful, and that is describing how to model the reality we want to automate using concepts that describe that reality to a software engineer, without necessarily being real terms used by doctors.
On the other hand, the actual computing system implementing a solution for this domain need not at all declare classes and objects that correspond to what I put in the diagram, so it’s not a software design diagram either. It may, for instance, be much more convenient to design “issue worksheet” as a group of classes, none of which directly corresponds to that “issue worksheet”.
In other words, my “domain model” is a bastard construct, neither a real “domain model” or a real “application design model”, but it is darn useful. It can be explained to domain workers (in our case, doctors) and they are able to see what I’m driving at, and it can be explained to software developers, so they can form a picture of what the actual workflow is that we need to support. This model allows understanding and discussion of the problem domain. It’s a bastard, but a good bastard.
If you subscribe to “domain-driven design”, you won’t like it, though, since you have to implement domain concepts as software design concepts, else it’s not “domain-driven design”. In this case, you’d be forced to implement classes for “issue”, “issue worksheet”, “privacy”, etc. In my opinion, that’s a naive and unnecessary constraint on software design that doesn’t give enough advantage in return to warrant the suboptimal design that results. So sue me.