3 ms·

DCI piqued my interest when I first heard about it. It seemed to solve some problems I was seeing in the typical model structure of MVC apps. In the end while I

DCI piqued my interest when I first heard about it. It seemed to solve some problems I was seeing in the typical model structure of MVC apps. In the end while I still agree with the principles behind context (keeping the primary workflow of a code module linear and organized in one place) I found interactions (mixing in behaviour with data) to be largely unnecessary in actual practice. The problem DCI purports to solve with OOP is in fact largely caused by failing top apply OOP properly (yeah, yeah no true Scotsman...). Issues like overloading objects with too many responsibilities (MVC models do this almost always), relying on inheritance when composition is what is needed, not defining and enforcing module or transactional boundaries and naively applying DRY to everything all lead to high coupling and low cohesion and ultimately cause the problems that DCI attempts to solve. However they can be solved by simple avoiding the above and using simple principled objects with clear dependency trees and boundaries. Bottom line: Follow the basic principles of OOP and SOLID instead of just paying them lip service and no secret sauce is required.

_pmf_ 9y ago
As I understand it, DCI slims down classes by moving contextual responsibilities in a contextual helper class. DDD shifts this problem by introducing the Bounded Context concept, where you are encouraged to have, for example, a dedicated, specialized "User" class in the "Billing" context and another specialized "User" class in the "Content" context (and having mappers/adapters between these two classes). Does this align with what you are saying?
techno_modus 9y ago
It seems that they are trying to develop a model where object behavior can be restricted or modified depending on its uses. In fact, it is a quite important problem and there exist many general models and specific techniques which tackle different aspects of this problem, for example: o Aspect-oriented: Additional behavior can be injected into classes https://en.wikipedia.org/wiki/Aspect-oriented_programming https://en.wikipedia.org/wiki/Aspect-oriented_programming o Context-oriented: Behavior depends on the context http://www.jot.fm/issues/issue_2008_03/article4/ http://www.jot.fm/issues/issue_2008_03/article4/ o Concept-oriented: Behavior is split between references and objects http://conceptoriented.org/ http://conceptoriented.org/ o Subject-oriented: Behavior is split between objects and subjective perceptions (subjects) https://en.wikipedia.org/wiki/Subject-oriented_programming https://en.wikipedia.org/wiki/Subject-oriented_programming
cshenton 9y ago
Do you think most devs spend enough time thinking through a good way to model what they're building?
- pbourke 9y ago
  In my experience, most devs start with an ORM/data store/framework/pattern and try to shoehorn the solution into it. I think Domain Driven Design[0] has held up well as an alternative to this - especially the strategic design patterns. The DDD strategic patterns are all about expressing the model in the domain language and finding the boundaries around clusters of interrelated model concepts (DDD calls these "Bounded Contexts"). DDD is often mentioned alongside CQRS[1] these days, but it also works for plain old OOP and functional systems as well. [0] https://en.m.wikipedia.org/wiki/Domain-driven_design https://en.m.wikipedia.org/wiki/Domain-driven_design [1] https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html

_pmf_ 9y ago

As I understand it, DCI slims down classes by moving contextual responsibilities in a contextual helper class. DDD shifts this problem by introducing the Bounded Context concept, where you are encouraged to have, for example, a dedicated, specialized "User" class in the "Billing" context and another specialized "User" class in the "Content" context (and having mappers/adapters between these two classes). Does this align with what you are saying?

techno_modus 9y ago

It seems that they are trying to develop a model where object behavior can be restricted or modified depending on its uses. In fact, it is a quite important problem and there exist many general models and specific techniques which tackle different aspects of this problem, for example: o Aspect-oriented: Additional behavior can be injected into classes https://en.wikipedia.org/wiki/Aspect-oriented_programming https://en.wikipedia.org/wiki/Aspect-oriented_programming o Context-oriented: Behavior depends on the context http://www.jot.fm/issues/issue_2008_03/article4/ http://www.jot.fm/issues/issue_2008_03/article4/ o Concept-oriented: Behavior is split between references and objects http://conceptoriented.org/ http://conceptoriented.org/ o Subject-oriented: Behavior is split between objects and subjective perceptions (subjects) https://en.wikipedia.org/wiki/Subject-oriented_programming https://en.wikipedia.org/wiki/Subject-oriented_programming

cshenton 9y ago

Do you think most devs spend enough time thinking through a good way to model what they're building?

pbourke 9y ago
In my experience, most devs start with an ORM/data store/framework/pattern and try to shoehorn the solution into it. I think Domain Driven Design[0] has held up well as an alternative to this - especially the strategic design patterns. The DDD strategic patterns are all about expressing the model in the domain language and finding the boundaries around clusters of interrelated model concepts (DDD calls these "Bounded Contexts"). DDD is often mentioned alongside CQRS[1] these days, but it also works for plain old OOP and functional systems as well. [0] https://en.m.wikipedia.org/wiki/Domain-driven_design https://en.m.wikipedia.org/wiki/Domain-driven_design [1] https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html