Ever notice that when you go to a company that supposedly uses an MVC structure, there’s an inevitable problem when it comes to controllers and models? Most people won’t fuck up the view section since even the lamest front end programmers know how to separate html from business logic. However, even seasoned backend developers tend to fuck up the M and C aspects of MVC.
Although I’ve talked in the past about how I prefer the notion of MOVE (models-operations-views-events) over basic MVC. There’s an even deeper problem that stems not necessarily from the inability to segregate code properly, but something that seems endemic to most programmers: the inability to understand domain modeling.
I think it’s this issue which is at the core of a lot of companies’ architecture problems. And it’s not an easy idea that can go away in a day either. The issue lies in understanding domains or even more fundamentally the basics of OOP.
This topic was brought to my attention when a former co-worker of mine asked me about some OOP issue he was struggling with. Although he wanted a simple answer, I could not provide one because I feel that OOP, domain modeling and setting one’s goals in all of this are not trivial.
OOP and domain modeling are all about understanding the problem you’re attempting to solve. When you start to think in coding constructs and other structures or design patterns before attempting to address the problem, then you’ve already failed in grasping some of the basics.
His issue was that he wanted to simplify something that sounded like a POJO in PHP. It took me some interrogation to probe what exactly he wanted to do. But that’s the way I think about such things when trying to educate someone who might lack the experience level in modeling/OOP design. It’s not so much to me about creating something simple or some killer coding methodology. I need to figure out what I want to accomplish first.
When it comes to corporate systems, things are even more difficult because of how businesses tend not to truly understand the thing they are attempting to solve. If I don’t know the thing I’m attempting to build, how can I accurately come up with something that models the problem I want to solve?
I had an interesting discussion about this subject with another coworker who had a better grasp of OOP. In that discussion, I talked about how a model of a tire might be different for an auto manufacturer compared to a tire company. For the auto manufacturer, the car itself is the domain object that I’m modeling while the tire is a component of the car. The tire might not necessarily be the focus of the car so it might not have much meaning when you take it out of the domain. However, compare that to the tire maker where the tire is everything. These two examples show at a high level the notion of object composition. But where things become relevant all depends on how the business sees it.
And that’s where the difficulty lies and where domain modeling becomes exceptionally difficult. Domain modeling here isn’t just about exposing a bunch of setters and getters. It’s about exposing the functionality that provides inputs and outputs to that domain object. If we go back to the car vs tire example, one could say that the only thing that the car domain object would care about is whether or not the tire is attached or has a flat. The tire domain object might provide inputs like a gauge that talks about the air as a feedback system back to the car’s computer. However, the car wouldn’t care what type of rubber the tire is made of nor would it care about how the tire was originally made. Those are details of the contract that the tire manufacturer does not need to provide but would hide in their API.
Then when you get into many companies, especially at the web level, I feel that these ideas become lost to them because they’re too focused on some 3rd normal form database or other document storage types of systems as opposed to asking deeper questions to create a more coherent architecture. At that point, MVC only becomes a convenience to hire developers rather than a strict enforcing methodology with principles for which developers would be able to engender well thought out objects.
I think a lot of the problem ends up occurring because of the database artifact quite honestly. Web technologies and conventions have royally screwed up good programming practices because of how databases are structured. People often worry more about details like caching, database handlers, etc. as opposed to well formatted APIs. The result ends up becoming these cludged up systems where the code is disorganized, inconsistent and bulky with little hope for re-use.
The other thing that came to my attention in talking to my coworker was eliciting the target audience of the code base. It ended up being a personal project, so I told him that there’s two ways to go about doing things: 1) if you just want to get something done, fuck it. Don’t worry about structure or coding methodologies. Just make sure it works; 2) if you’re doing this to improve your knowledge of coding by giving yourself more practice, be strict on what you’re doing. Attempt to adhere to good principles and try to understand why certain principles, albeit seeming painful, exist. In short, think about the problem you’re trying to solve, not the way you’re solving it first.
Of course, at the corporate level, most people do not receive this luxury. Typically, developers are out of time and must resort to desperate programming practices. And realistically, the thing they are attempting to build will be vague so modeling such a thing would be akin to taking my mom to the acupuncturist. But I still feel that you should always first try to establish the problem you’re attempting to solve before trying to solve it. Figure out the inputs/outputs, the processing that occurs as a result of the inputs that produces an output, determine the adjectives or other descriptive aspects that make up the object’s details and description as well as it’s connections to other related objects and the actions you want to expose. If you think like this, your code will start to feel more elegant and scale better in the long run because you’re working against an API not just the details of a problem you think you’re attempting to solve at the moment. And that aspect is good code.