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.
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.
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.