The problem with MVC [introducing Triple D]

Here is the problem with MVC; it is not fit for the purpose to which it is often misused.

I have had endless arguments with developers over what is the Model and what is the View and what is the Controller and where the line is. The problem is that line is obfuscated.

What is a "view" or a "model" or a "controller"? It should be pretty easy to define, but it simply is not. A database instance is a de facto example of a model (assuming your application has a database). But a database can also contain a view. Your GUI is a view, but it also has a model, but it isn't the model from MVC, it is simply the model of the GUI, and so on.

MVC is fine at a high level. We can say Apache Struts is MVC. An Architect can say here is the "Model" and this is the "View" and this is the "Controller". But at a granular level this becomes more complex to discuss in an MVC context.

At the lower Object Oriented level developers require a common language that help them identify specific classes and their purpose. Enter Triple D.

Triple D = Doing Data Display (DDD)

This is a way for developers to discuss and purpose lower level objects without getting confused with MVC terms.

There is much more to discuss on DDD, but the premise is simple: Every object in a system has a purpose. It is much easier to identify that purpose if you can quickly categorise that object.

Each level of either M, V or C can contain all three types of Dobject and by categorising the object in Triple D and documenting it as such, following developers can know instantly what additional things they should or shouldn't add to that object.

Objects can be one or two Ds, but never all 3. If you have objects with all three Ds then you have failed every aspect of Object Oriented Analysis/Design/Programming.

Example: An object provides a GUI button for display. By this we know that it has to be a Display object. We also know that it needs to display some kind of text which can be set to it, so it is also a Data object. Therefore, it should not be a Doing object as well.

Looking at existing GUI frameworks we know this to be true. When we create a button we pass it a listener (Doing) object that will perform some business logic when the button is pressed.

By sticking to the Triple D principle developers can easily communicate during any stage of development what  type the object is and isn't, without trying to apply MVC to low level objects.