Given teams in which the responsibility of designing the domain isn't delegated to any individual team-lead or architect, I see it time and time again: solutions implemented with an overt focus on the technical aspects. Faced with a problem the business needs solved, the developer's mindset aptly turns to thoughts on architectural frameworks, methodology styles, immediate speculations of which layer goes in which physical tier, etc. Seldom, in my experience, are the initial notions reserved for modelling the domain.
Be it green-field projects or legacy systems maintenance, I have witnessed developers desperate for domain know-how search left and right for any semblance of a domain model. As they discover none is available, they'll turn to a project manager who'll get the business-knowledge they need to get the job done, or they'll seek out a corporate character and find the info waiting for them here. Yet - given the team without a designated lead-developer or architect - they think of solving only the issues at hand. And when the task has been cleared and the problem thus solved, too often there seems little incentive to anchor that domain knowledge - either by commencing the construction of a domain model, or at the very least documenting the rather valuable information.
And so the domain knowledge isn't shared, rather it stays inside the developers head, to be neglected and forgotten over time, or disappear altogether when jobs are changed.
Given A) teams with no clear leader, B) developers free to prioritize and C) no pressing deadlines to be honored, why - in my experience - does not the developer assume a greater responsibility for modelling the domain to the utmost extend? The merits of which remain unchallenged.
It cannot be a generation gap issue. I have seen it with the junior as well as the senior developer. Nor a gender gap; I have noticed no discernible difference with male vs. female developers. Nor a training bridge too far; most educations and courses offer at the very least a mention of the benefits or domain modelling.
I suspect one or a combination of the following are at fault (in no particular order):
- With no established lead to follow, few desire to be the first to pick up the mantle, of fear of doing damage to the established work-place structure or etiquette. Building and sustaining a domain model is a joint effort - but how can one be sure the group is up for it?
- There is truly nothing even in lieu of a domain model, which triggers insecurity in starting one to begin with. The "no-one has so far, so why/how/when/where should I?"-issue.
- The developer's ego. We're adept at solving technical problems, and most of our training and wherewithal tends to that - so that's where we desire to shine.
- The perceived tediousness of talking about business issues, when one could be happily coding away.
- The rapid technological shifts. We have to keep track, in order to enhance our prospects
and chances of a fulfilling career, and satisfy our tech-savvy conscience; we invest more in ourselves rather than the workplace.
- Perceived job-security: the subconscious notion of "they can't fire me when I'm the only one who knows about this stuff, so I won't document it".
- Poor knowledge and use of tooling; developing (not designing) an anemic domain model around a set of domain objects, automatically constructing a database and repositories around that and believing that to suffice, as it's easily supported by the developer's tool of choice.
Given even a minor complex domain, I find this to be unacceptable. Shying away from modelling a domain is detrimental to the health of the business, herein failure to sustain business know-how, failure to communicate, failure to become flexible in the face of changes.
I submit that it's never too late to do domain modelling, and further that it's entirely possible to do domain modelling as an afterthought. Certainly it's not ideal, but feasible - and will add value. Though DDD remains my preferred approach, I'm not here advocating it as the sole approach; basically any approach will do, as long as it adheres to the core of the business and, in the end, the reasoning behind applying information technology to enhance it. I propose a "low and slow" means to the end. "Low" as in a single object library, identified from rudimentary traversal of, say, screenshots of an existing application, is definitely fine for starters - as long as it forms the basis of a declaration of intent, i.e. a) it's version controlled for the team to see, b) it's concisely annotated, and c) it's been validated by the business - no meetings required, a simple "let me run this by you real quick" will suffice. "Slow" in as much as it needn't be a huge effort up front, it might be ten minutes here and there, drawing a diagram, validating it, cooking up a basic entity class to represent it.
To be sure, it requires a bit of discipline, and if you haven't got it, forget it. But if you do, over time - given a few hundred of those aforementioned ten minutes - the domain model will emerge. And you will be adding value. To the business, and to yourself.
