Anatomy of an Ogre

work safe

Just a quick refresher of my last post; I hate layers and prefer the ports & adapters architecture I drew in the following picture.

Ports and Adapters

The next logical thought is probably, “Okay Mr. funny man. What the heck is going on inside that big green blob?” The same thing you should put inside the green part of the layers picture. Oh, the n-tier app guys don’t talk about that very much, do they?

The easy first draft of the green layer is to simply takes the objects you’ve mapped on to your data store, right? This works for many situations where the UI is essentially directly manipulating the underlying data. This is what Trygve Reenskaug had in mind when he codified the MVC pattern. It is also close to the Naked Object pattern.

But it falls down with complex inter-object interactions. The problem is just your normal run of the mill OOP as widely practiced, the translation of nouns to classes. You end up with jealous classes, classes with multiple responsibilities, and a bunch of untested business logic repeated in your controllers/activities. That means that your probably have an implicit relationship hiding in your code.

When these relations and interactions are important enough, they should be made explicit by creating An object to manage interactions. This is better OOP, but I’d you need some ‘further reading,’ try taking a look at Domain Driven Design or Lean Architecture’s DCI. They both get to similar places, but with slightly different paths. DDD shuns the anemic domain model favoring rich behavior; while DCI favors simple data objects that compose with traits to which own behavior to be used in context objects managing their interaction.

I’m currently leaning towards a DCI inspired approach. First, DCI is a when necissary approach. If simple MVC/MVVM/etc work, then lean towards that. When, however, a use case gets complicated enough, you reach for the DCI to simplify the controller code. I can’t claim to use pure DCI since not all environments in which I develop have ‘traits’ or some similar code composition mechanism, but what is interesting is starting to think about your controllers acting on contexts and not directly on the data. And a context is nothing more than your use-cases turned in to code. the other parts of DCI are the data and interactions. Data is just dumb data, what DDD calls an anemic domain object. An interaction is a trait applied to a data object enabling it to play a role. Interactions are not necessarily meant to be widely reused as each collection of context and interactions can be thought of as a bounded context. If you don’t have traits then consider this non-exhaustive list of the following fine options; a context specific subclass, a decorator, a wrapper object, or interface aggregation.

What’s good about this approach? For starters, it is far more testable since you are controlling the BL interactions with easier to mock interfaces. In addition, the explicit decoupling of regions of a complex page mean you will be more aware of interactions between those controls, and we’ve all had pages that start to have emergent behaviors and eventually end up sentient. You know, the one that keeps getting the change requests and bug reports.

Some further reading:

1 Comment

No Comments

1 Trackback

Leave a Reply

Allowed tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>