Sysadmin Field Notes

April 17, 2006

Gregor starts with some good explanations of what makes code readable in March is Not a Number., using examples from Eric Evans.

I'd add that when doing this sort of coding, a definite design smell is when you start mixing domain specific languages. It's likely in this hacked together web world that you really have several domain specific languages. Somewhere you're logging a user in with cookies, calling a web service to verify someone's identity, making some business decisions, or retriving a customer profile via an MQ message. All of these layers form their own little domain specific languages.

So how cleanly these languages are separated I think makes a good canary for how readable your code is. The code has readability problems if you're pulling a value directly from the session, checking against something it in your domain model, then directly calling a generated web service proxy and catching soap/http exceptions.

A business person doesn't understand (necessarily) http, or the concept of a session. If you really have a domain driven design, then someone who understands the web should be able to look at your web layer and get what you're doing with cookies and the session. The business person can look at the core logic and not see implementation related cruft. And the back-end code can be understood by server side developers who understand web services and all the things that might go wrong while calling them.

The more seperated your concerns are, the more readable your code probably is. I do hope you have good refactoring/code navigation tools, because sometimes this stye can get a little deeply nested. I don't think that's a problem; I prefer it that way.