Looking at the List (1 of 6 or 7)

I posted a list of ways that development has changed since the days we thought we knew how to design applications. I want to clarify a few things on this. This is about design or approaching architecture – it goes beyond OOD per se. I started out from that perspective because we believed when we were doing OOD that we could get our heads and hands around designing our applications. We can’t anymore, and it’s the changes I’m identifying here that keep us from that holistic approach.


I’m sharing with you a process of getting back to that holistic approach. We first have to understand the problem.


But calling this a problem is itself problematic. The items on this list are the things that make development great. When I asked Bill McCarthy about this list he said “oh you mean your list of the fun stuff about programming”. This really is the stuff to celebrate. But in the meantime, it’s making us a bit insane.


I want to walk through each of the 60 items. To do this, I’m going to split the list into groups of ten so it doesn’t get too overwhelming:


1.  Parallel entities

Instead of creating objects that do their jobs, we create sets of objects that work together to supply required plumbing before we even arrive at the point our business objects can start working. We have many entities and they have identical or nearly identical structures. In addition to a vertical design, we have a horizontal design that is at least as important.


2.  N-Tier

The horizontal structure stretches across many layers, at least potentially. These layers are essential to proper functioning and performance, and they are quite likely to evolve over the lifetime of the application.


3.  Sheer magnitude

Some design aspects, including visual drawings and CRC cards break down when the number of objects is very high – on the order of hundreds, not dozens.


4.  Application code generation

Generating code means we design certain things at the template, not object level. It also means we can change our design during the application life cycle which significantly changes up front planning.


5.  SOA (Service Oriented Architecture)

Service oriented architectures means we’re writing about tasks and basically designing significant portions of our applications one step higher than business objects. These services interact, not the objects within them.


6.  Semantics and canonical messages

Semantics and canonical messaging becomes very important in diverse organizations. The concept of an object is tightly coupled to its name in traditional design and must be decouple to provide a canonical view.


7.  Workflow

Like SOA, Workflow uses objects for task sequencing and works more at a task level of thinking than an object level. However, unlike SOA, these services need to be small grained to allow flexible combinations, instead of large grained for communications.


8.  Rules engines

Rules engines mean that our objects may not know what will happen when they run. They do not even know their own dependencies.


9.  Aspect oriented programming

Aspect oriented programming means we run code in unique ways based on attributes – especially delegates on attributes. .NET has a poor AOP model and this is largely a future looking item.


10.Impact of libraries

We no longer live and breathe isolated applications, but applications where much of the code is long lived and reused. These libraries have to be planned and maintained for the greater good, not the benefit of individual applications.



One thought on “Looking at the List (1 of 6 or 7)”

  1. The link to the docx file is broken.

    And as a comment to your article: aren’t all these “new ways” dependent on the hardware? At first there was no concept of layer, then, as the technology allowed, layers of abstraction were either added or expanded.

    But shouldn’t the compilers try to break the onion of layers and get to the result as best as possible? I mean the programmers and code reviewers need layers to better understand what is going on, but the computer doesn’t need them.

    I believe that the next step is to make the compilers break the encapsulation when possible. Wouldn’t it be great if one could code in layers and the actual compiled result would work like the good old fashioned “one-piece” software?

Leave a Reply

Your email address will not be published. Required fields are marked *