Yes We Can!
The developers have spoken, and change has come to our code!
OK, so I’m a tad late. Last November, my department announced the next version of the design of our code. Actually, when I first started in July, my boss’s boss mentioned that this was coming down the pike, complete with an underground team hard at work, but I was skeptical.
The first is called “legacy.” I’m not really sure what the guiding principle was. The second, and current, is procedural SOA.
Now, starting this year, a migration will occur to move us to the Evans Doctrine of Domain Driven Design!
I am ready to accept your apologies for doubting me. I am noticing a pattern. Listen carefully.
First, I stood alone as a DDDer in a sea of procedural Java. Now I’m not sounding so crazy anymore.
Then at karate, I stood alone as someone who is a stickler for details. Lately, I’m not sounding so crazy anymore.
Then during the last election, I stood alone as someone who wasn’t going to support the lesser of two evils. I was apart from my parents and even El Rushbo. Now, after The Maverick got wiped out, I’m not sounding so crazy anymore.
The lesson? Don’t doubt me.
We are going to use all the building blocks:
- Entities
- Value Objects
- Aggregates
- Factories
- Services
- Repositories
- Specifications
- Associations
It’s going to be complete with Subversion, Maven, Nexus, Hudson, Spring, AOP, and Structure 101.
Pretty inspiring stuff.
The underground team members spoke of heated debates on where seemingly simple behavior should go: the entity, the value object, the service? And this is awesome, because in an object-oriented system, this is the central question. That IS the design.
It’s a people problem, though. Indeed, one of the characters from Nowhere To Run:
yes, that guy, Steve the Procedural Programmer, quipped that Value Objects sounded “like data buckets. I thought those were bad.” Steve, what part of “behavior moving into the objects themselves, where appropriate” don’t you understand?
Don’t be surprised. When yours truly was gave a presentation earlier on Structure 101, Steve dismissed out of hand all of the features of the tool except the RAD plug-in, after which he was summarily lectured by another architect in the room.
As a test, I floated a weather balloon to the architect presenting the latest details on the new plan.
In “SOA”, if I declared an entity had a private member of type int, this information leaked to at least three or four classes. And if I had to change that later on to a long, I break those same classes. How, oh architect, how would this change in the new design?
Almost as if he had read my self-diagnosis of OCD, he described a Value Object-based approach of hiding the type.
Now I end up asking myself: how, after reading both Evans and Nilsson, how was this not apparent to me?
I can tell you one thing: this type-hiding was not present in Evans in a few of the code examples presented. I refer you to the paint application example in Chapter 10: Supple Design, page 248, and the brokerage account example in Chapter 5: A Model Expressed in Software, page 85. Both examples feature getters that reveal the types of attributes on a domain object.
Certainly, I don’t have the Nilsson book handy, but I do not recall the code examples there preaching type hiding either.
I certainly had parts of the solution. I knew about Value Objects. I knew about Primitive Obsession. I knew about Holub’s export-as-string argument. I knew about Tell Don’t Ask. I knew about the permissibility of domain-coupled getters.
What I didn’t do was put this all together. What I didn’t recognize was going on, and what the Evans examples cited above suffer from, is a leaky abstraction. And it seems now so obvious. It seems like the end of the debate (hah): attribute-level type hiding.
Was this idea a basic object-oriented programming principle that I missed out on in college? Why did I have to hear about this on the streets?
Remember, every bit of sarcasm has some bit of truth about it:
There’s no problem in Computer Science that can’t be solved by adding another layer of abstraction
 |
Announcer: You’re reading the EIP web-ring. |
