My last post about DCI and Rails triggered many interesting discussions. One of the topics that came up very often can be summarized to this question:
Do you think of your web application as an application or as a set of resources?
My answer is clear: it's an application.
I noticed that not everyone agrees with it.
In the Rails world a resource is a very popular word. Mostly because of the REST architecture that we follow in our apps. Whenever I can I use the REST approach, but I think of it as a way of using URL's and accessing the application. I find it a nice way of structuring my controllers. REST is just an interface. From outside and for my users it's an application, not a set of resources. They use resources but they access them through an application which to me is an important distinction.
This topic caused that I decided to publish the assumptions that are needed for a DCI architecture, at least how I understand it:
1. As developers we model the real/business world.
2. If a concept appears in the model we reflect it in the code.
3. Most of the web apps scenarios has the pattern of "a user does something with the app"
4. If user and app are so important in the domain then we make them classes/objects.
5. It results in big user/app classes.
6. The problem of big classes can be solved by using the idea of "injecting roles" runtime.
Usually point 5. discouraged people from reflecting the user/app importance in the code. The alternative is chosen which is things like this in the controller:
@discounted_products = Product.discounted
whereas I prefer this:
@discounted_products = shop.discounted_products
# shop is like the application object here
Anyway, point 5 can be now solved by the idea of injecting roles and DCI as described in my last blog post and in my opinion we can start using the user and application objects more often. Once you start using them, many of the OOP decisions you need to make become easier, because you just reflect the domain in the code.