I've been thinking a lot about domain-oriented OO vs pattern-oriented OO because domain-oriented OO is usually thought of as "unteachable," and that fact showcases the way developer education is broken.
Domain-oriented OO is hard for current dev education paradigms for two reasons:
1. It is a subjective craft. Subjective crafts require art-school techniques, not "here's how pointers work."
2. It is not about building a static artifact. It is about building team understanding.
1. It is a subjective craft. Subjective crafts require art-school techniques, not "here's how pointers work."
2. It is not about building a static artifact. It is about building team understanding.
Most attempts to teach the “craft” of software have fallen flat because the “artisan” metaphor emphasizes individual work and a static end product.
Software is a living system, created by teams collaborating with both themselves & past software versions.
Software is a living system, created by teams collaborating with both themselves & past software versions.
But it’s not just that you can’t teach team skills in an individual setting, or that you can’t teach living-system skills with assignments that focus on the end product.
It’s that subjective crafts skills are vulnerable to illusions of understanding.
It’s that subjective crafts skills are vulnerable to illusions of understanding.
Back to domain modeling: Does a `User` class have a single responsibility?
Folks often look down on folks who say yes. They look at their 5KLoC `User` class, say “Hah! No~!” despairingly, & go on about “presentational” or “persistence” responsibilities.
It’s a trick question.
Folks often look down on folks who say yes. They look at their 5KLoC `User` class, say “Hah! No~!” despairingly, & go on about “presentational” or “persistence” responsibilities.
It’s a trick question.
Given a `User` class with presentational & persistence logic, whether it has a single responsibility depends on where you’re looking at it from. If it’s effective as a black box, it might be single-responsibility “enough” for consuming code, even if it has a wide API surface.
But sometimes cramming everything “user” related into the User makes it too big to understand on its own terms, even if it’s still more-or-less consumable.
This is when folks start handwaving about “single responsibilities.”
It’s where pattern-oriented OO steps in to “save” us.
This is when folks start handwaving about “single responsibilities.”
It’s where pattern-oriented OO steps in to “save” us.
Maybe there’s a chunk of code in the User model related to the profile their friends see, and another summarizing history for admins.
“A-ha!” says someone who has been trained in pattern-oriented OO. “View logic!”
They extract a FriendUserPresenter & an AdminUserPresenter.
“A-ha!” says someone who has been trained in pattern-oriented OO. “View logic!”
They extract a FriendUserPresenter & an AdminUserPresenter.
The domain-oriented view of the same problem might instead be to extract a UserProfile and a UserHistoryAuditLog.
But there’s no easy heuristic for this. There’s “ask users what they see,” but that’s only “simple;” it’s not at all easy.
It’s much harder to teach effectively.
But there’s no easy heuristic for this. There’s “ask users what they see,” but that’s only “simple;” it’s not at all easy.
It’s much harder to teach effectively.
“Find the nouns,” all too often, leads people to a `User` class and lets them feel like they can stop there. This is a simplistic and illusory understanding — but without external feedback, how are people supposed to know they’re misunderstanding domain-driven OO?
It gets twistier: early in the lifecycle of an application? When the User class is 50 lines, not 5000? There shouldn’t be a separate UserProfile. The need for one lies in the way the code deforms around actual users’ emergent understanding that they have profiles.
The trick is, domain-oriented OO isn’t teachable through a series of “Five React+Redux-Sagas Tricks You Never Knew!” videos on egghead.io. It’s only teachable by contextualizing its skills in brownfield software projects, with lots of peer & teacher feedback.
