Sunday, September 9, 2018

A Gift of Three Poems from a Reader

1 b
A cynic is a man who knows the price of everything but the value of nothing.
~ Oscar Wilde (Irish poet and playwright extraordinaire)
LISP programmers know the value of everything and the cost of nothing.
~ Alan Perlis (American computer scientist, and the first winner of the Turing Award)
Beauty, as they say, is in the eye of the beholder. So it is with value: It's all too easy to miss seeing the worth in a thing or things, even more so when it comes to grasping the worth get compounded when seemingly unrelated things are seen in the context of their interdependence. So let's shed some cynicism and see how far it'll take us ๐Ÿš—

First, though, let us all rejoice in the knowledge that we have been given the lovely gift of three poems by a reader of Programming Digressions; plus, needless to say, you all needed a break from my ramblings anyway, didn’t you? So there you go, your wish has been granted and your dreams—for now anyway and until my next rambling-filled essay—have been realized ๐ŸŽก

Before I introduce our benefactor who has given us this gift, allow me to answer a question which, dare I say—judging at least by the knotted brows on your forehead—is percolating right now in the nooks and crannies of the minds of many: Will this particular essay make me a better programmer, a better technologist, the author of beautiful code? ๐Ÿ˜ฒ

The brief answer is: It depends.

For a slightly more elaborate answer, check the framed pic below…
Automata b
Computer science is no more about computers than astronomy is about telescopes.
~ Edsger W. Dijkstra (Dutch systems scientist, programmer, software engineer, science essayist)
— Reader: “Wait a second, Akram, what is that book (Algorithms, Languages, Automata, And Compilers: A Practical Approach) doing in the pic above? And are those tape flags you got plastered along the right-hand side edge of its pages?"
— Akram: "Yep, here’s the deal: Standing upright next to another fine book, that one all about poetry (The New Oxford Book of English Verse) is Exhibit A in my argument to demonstrate that it is unwise to circumscribe the branches of knowledge into a knotted ball."
— Reader: “There you go again, Explaining metaphysics to the nation. I wish you would explain your Explanation! And yes, that's straight from Lord Byron's Don Juan: Dedication. So don’t you be fooling us now, Mister."
— Akram: “Hey, hey, hey, easy now. What’s up with (the appearance of Algorithms, Languages, Automata, And Compilers: A Practical Approach in) Exhibit A is simply this: A memorable quote which can be found in its pages—one that fits the hand like a glove when it comes to our essay's themeleft quite an impression on me when I read it a several years ago…"
— Reader: “And what might that quote be, Mister smarty-pants?"
— Akram: “Yo, what’s the deal about this smarty-pants? Anyhow, glad you asked. That quote helped tie several loose threads for me, especially as it pertains to the theme—that it is unwise to circumscribe the branches of knowledge into a knotted ball—of this essay. It goes like this: Studying the theory of computing will not make you a better coder in a matter of a couple of weeks, but understanding the foundations of computer science will certainly increase your problem-solving and programming abilities."
— Reader: “Great, now everything is clear as mud. And the only knotted ball—turning the tables on you by using your own metaphor, ha!—that comes to mind is the anti-pattern, for crying out loud, and which we all know and dread as The Big Ball of Mud, so there!"
— Akram: “Gulp, this reader knows her stuff; no pulling wool over her eyes."
— Reader: “What else you got for me, Akram? And hey, by the way, what are those three outlandish balloons in the pic at the top—the ivory unicorn, the Tigger-like Tiger, and the Winnie the Pooh-like bear—floating around for? Is this symbolism or something? Dang, Akram, you trying to pull wool over our eyes again?" 
— Akram: “No, no, no, nothing of that sort. Symbolism notwithstanding, all I'm trying to do with those three fanciful balloons is to draw your attention, a tad subliminally, I must confess, to the three splendid points around which this essay revolves, locked in geosynchronous orbit."
— Reader: “Geosynchronous, what?!"
— Akram: “Tell you what, for the sake of your sanity and mine, let’s postpone our discussion on that topic—along with the magnificent contribution by Arthur C Clarke in this area—to a later time, shall we?"
— Reader: “Sounds good to me. Plus, can we, like, get on with the essay proper?" 
— Akram: “But of course, my lips are sealed from here on. Get ready for a treat to stellar poetry."

 

With A Drum Roll, Introducing The Author!

With that, let’s introduce our benefactor, the giver of this gift: Kitty Fassett, a retired pianist and intellectual extraordinaire—her distinguished background and training in the art of music (Vassar College, and the Puerto Rico Conservatory of Music) are important aspects of her brilliant career. She has a finely-developed ear for the well-turned sentence, and who has given me much encouragement and extensive feedback on (drafts of) the essays that you read around here ๐ŸŽช

Yep, my essays are so much the better for her feedback! ๐ŸŽฏ

(As a matter of fact, some of you may remember another contribution by Kitty—the oh-so charming essay entitled Pop’s War: My Father, the CIA, and the Green Death—grace our blog about a year ago. Word to the wise: don't miss it!).

Oh, and since we touched on the subject of flight—remember those beguiling and blustery balloons, geosynchronous orbits, and stuff like that—it is only fitting that the very first poem by Kitty be all about space travel ๐Ÿ

Intrigued? (I am, for sure). Let’s get right to it!3 b

A Warning To Space Travelers ๐Ÿš€

by Kitty Fassett

Travel intergalactically
at your own risk.
The management assumes
no responsibility
in case you fall
into a
black hole
having foolishly
passed its pallid perimeter
past the point of no return,
lured by the personal magnetism
of the beast at the bottom,
finding yourself spaghettified
and stranded in darkness
forever.

4 b

The Cat Lady* ๐Ÿˆ

By Kitty Fassett

What is it about her
that makes her attractive
to cats bearing bounteous tributes
of rats
and snakes
and on special occasions
a rare tropical bird
which they drop on her doorstep
all dead on arrival
after a nocturnal orgy of prowling
observed in a dissonance
of yowling polyphony
outside her bedroom
window?

* Now for something, as follows, on what inspired Kitty to write this poem, by way of personal communication: "The cat poem was inspired by my years in Puerto Rico, where we had always a multitude of cats—as many as 13 at a given time. They left us presents on our doorstep almost every morning: usually dead rats, because we had a lot of those nesting in the surrounding coconut palms until we had them knocked down."

Speaking of Puerto Rico, anyone remember Castillo de San Cristobal? ๐Ÿ„
5 b

A Moon Poem ๐ŸŒ›

by Kitty Fassett

Before jumping with joy
in a ritual of adoration
remember that the moon
is crazy.
After beaming beguilingly
she retreats darkly betraying
a Byronic disposition
towards despondency
and though people say be patient
she’s just going through a phase
I say phooey she’s a phony,
just a glorified goddess
possessed pathologically
with a polarized
personality
disorder.

6 b
Sir Rider Haggard,
Was completely staggered
When his bride-to-be
Announced, "I AM SHE!"

~ W. H. Auden
And there you have it, poetic loveliness writ large by way of three splendid poems from a reader like you. Tag, it’s your turn now (Send in your contributions to me—prose, poems, whatever—and I'll make sure they get fair treatment on their way to getting posted right here in our digs!) ๐Ÿƒ

These three poems, I must confess, and each in its own way, remind me a lot of the poetry of W. H. Auden, a sample of which, incidentally—in case anyone was awake enough—appeared recently in an essay by yours truly on the subject of my recent adventures with the practice of the Go programming language. ๐Ÿ˜ด

Adios until next time!2 b

Sunday, August 26, 2018

Further Adventures In Go Land







A language that doesn’t affect the way you think about programming is not worth knowing.
~ Alan Perlis (American computer scientist, and the first winner of the Turing Award)

 

What Is This Essay All About? ๐Ÿ™


Glad you asked! For one thing, this won't be a boring treatise on some obscure aspects of the Go programming language—we don't do boring stuff here in our Programming Digressions digs—as I value your time and intelligence far too much. For another, I want to keep the fun in there as we go about tackling diverse subjects while providing substantial value to you ๐Ÿ’ฐ

This time around, we're going to explore exactly what it is that enables Go to pass what I'm going to call the Perlis test—"A language that doesn’t affect the way you think about programming is not worth knowing"—with flying colors ๐Ÿ

Yo, what exactly is that impish-looking octopus doing up there in the pic? Hold on, hold on, everything will become clear in short order (Hint: Programming languages do not exist in a vacuum;  they are relevant only to the extent that they serve a great goal. On top of that, how can 296 million years of evolution be wrong? Or ever wonder how IoT is evolving like an octopus? Go straight to Item # 11 below—"Bringing Go To The IoT World"—if you just can't wait to find out what this is all about!) ๐Ÿ™

And, of course, read on if you are intrigued. Oh, and should your dear heart so desire, feel free to think of this essay as a sequel to the one which had appeared some moons ago, the far more prosaically-named prequel The Go Programming Language ๐Ÿ™Š

With that, here's a rundown of what's coming your way today, right now, in fact:
  1. Duck Typing ๐Ÿ“
  2. Duck Typing Redux ๐Ÿ—ฟ
  3. Paradise Regained ๐ŸŽญ
  4. Of Object-orientation And The Platypus ๐ŸŒ
  5. Calming Down To The Soothing Rhythm Of… Unit Testing! ⛵
  6. If You Fall, I Will Catch You, I'll Be Waiting ⚾
  7. Whew, Sprawling Hierarchies No More ๐Ÿšง
  8. Go, Your Own Way ๐Ÿ„
  9. The Widening Gyre Of Concurrency ๐Ÿš…
  10. Go's Got Concurrency ๐Ÿ‘ป
  11. Bringing Go To The IoT World ๐Ÿ™
  12. Persistence In Go ๐Ÿ’ฐ
  13. Go Can Be Sweet ๐Ÿฏ
  14. Go Can Be Baffling (To The Uninitiated) ๐Ÿ˜ฑ
  15. Let Beautiful Designs Emerge ๐ŸŒน
  16. What About Recursion? ๐ŸŒ€
  17. Things Explainer: You're Kidding Me, Right? ๐Ÿ“ฃ
  18. Things Explainer: Redux ๐Ÿ“•
  19. Go Forth And Smell The Roses ๐ŸŒน ๐ŸŒน ๐ŸŒน ๐ŸŒน
  20. Deep, Yet Simple ๐Ÿณ
Meanwhile, just as we're about to dive in to the essay proper—hey, the following interlude isn't all that improper either—we find ourselves inadvertently eavesdropping on a lively dialog like so:
—Reader: Good things don’t last forever, now do they?
—Akram: Um, would you care to elaborate?
—Reader: Well, for one thing, you hadn't written for a while—at least we didn't see anything posted around here—and for another, we all reckoned that even if you (Heaven forbid) ever decided to resume your writing, you would come back remediated and share something sensible.
—Akram: Sigh.
—Reader [continues without missing a beat]: Yet here you are again, this time displaying a laptop (yeah, as in the pic down there) under siege by the tentacles of an impish octopus! And what about those two rodents scurrying across on the other side of that laptop, for crying out loud?
—Akram: Oh, allow me to explain: (1) That adorable octopus is nothing less than a splendid reminder of how the Internet of Things (IoT) is evolving like the millions of years of evolution whereby we got the octopus, and (2) Those two—I think you called them, um, rodents—are none other than close cousins of the Go gopher, yay!
—Reader: Okay, this time you really lost it. Bye.
—Akram: Wait!!! Come back, I promise you're gonna love this essay.
—Reader: Yeah right, and I'll be a monkey's uncle.
—Akram: Ahem, humor me for just a few…
With that interlude under your belt—or sash, to be sure—and whether you are ready or not, off we go now on our mind-bending adventure ๐Ÿš€

(As you may recall the premise at the outset—"A language that doesn’t affect the way you think about programming is not worth knowing—I've taken the liberty of calling this "our mind-bending adventure", and with good reason to back it up, as you'll soon see!)

1. Duck Typing ๐Ÿ“


So our adventure begins—as many adventures invariably do—early one morning in a sleepy suburb where we find ourselves in the home of a programmer (Yeah, try selling this adventure setting for a movie script!) Yep, as you'll conclude from the happenings in the picture above, our perky programmer is about to sit down at the breakfast table (his lugubrious laptop and the oracular orchid waiting for him) ๐ŸŒธ

But oh my! We already got some creatures scuttling about the programmer’s laptop: One octopus, and two gophers, all three with designs on the apple square center. What’s up with that, we all collectively wonder... ๐Ÿ˜ฒ

Not to worry, though; all becomes clear as soon as we spy the bash logo plastered to the laptop lid, right below the apple. But of course we knew it: Basically, the programmer is a gopher, right? ๐Ÿ€

Well, we are getting warmer (and it’s pretty early on a weekend morning anyway) as it dawns upon us—such brilliance, oh my!—that our programmer must have lately been been writing programs in the Go programming language. Which brings me to ask the crucial question: "We're all ready for duck typing, right?" ๐Ÿ’ป

2. Duck Typing Redux ๐Ÿ—ฟ


How about a half-decent definition of whatever this "duck typing" thing is anyway? Glad you asked, as I've got a fabulous definition that can be found—along with a ton of other good stuff—in a fine book by William Kennedy, Brian Ketelsen, and Erik St. Martin. Using the springboard of good old interfaces, the three co-authors of Go in Action (Manning Publications) enlighten us like so:
Interfaces allow you to express the behavior of a type. If a value of a type implements an interface, it means the value has a specific set of behaviors. You don’t even need to declare that you’re implementing an interface; you just need to write the implementation. Other languages call this duck typing—if it quacks like a duck, then it can be a duck—and Go does it well. In Go, if your type implements the methods of an interface, a value of your type can be stored in a value of that interface type. No special declarations are required.
That's duck typing for you. How good is that? I couldn't have put it any better myself! ๐Ÿ

My hope here is that you are warming up to my choice of this essay's name (which is, ahem, Further Adventures In Go Land, in case you didn’t notice). But that's only half of the story: Truth be told, I had seriously considered naming this essay: “Go bash the C Shell”.

Can you even imagine the kind of reception that would have created in the audience, given the swirling mists of confusion already enveloping us. But reason prevailed, and here we are, with an essay that's got a far more prosaic title (namely, Further Adventures In Go Land).

(As for our jaunt into "Go Land"—and it's tight (linguistic) connection with yet another awesome product from the minds at JetBrains—we simply don't have room in this essay for catering to that…)

All fine and well, you say, but what’s up with that spoon-billed duck above?

Glad you asked: Our resident programmer—him of the sleepy suburban house—is coming down to his breakfast table and about to make everything as clear as mud, um, daylight, I meant to say! ๐ŸŒž

Duck typing can be a beautiful thing, especially in programming; actually, only in programming (I have yet to see a duck doing any kind of decipherable typing. ๐Ÿ’ Hmm… Come to think of it, I have heard of the phenomenon—one commonly afflicting us technology types—known as chicken scratch. But I digress) ๐Ÿ“

3. Paradise Regained ๐ŸŽญ


It turns out that our programmer was pondering exactly that—duck typing and stuff like that—when he spied his favorite cereal on the table. Needless to say, the cereal had to be wolfed down first before we got anything out of the programmer (Hasn’t anyone told him just how overrated nutrition is? I mean, it’s right down there with sleep. But I digress again). Soon enough, though, our rejuvenated programmer has rubbed his eyes, and is awake enough to give us the scoop on duck typing ๐Ÿธ

It goes something like this...

Yo, so in case you haven't noticed, Go does not offer inheritance or sub-typing. But guess what? We do have interfaces, yay! Any and all functions that implement the methods of an interface thereby automatically satisfy the interface contract (This is done implicitly, with nothing additional to be done on the programmer's part). Enter duck typing: "If it walks like a duck and quacks like a duck, then it's a duck." ๐Ÿฅ

Allow me to quote on this very subject from the canonical book on Go programming, again in the context of—you guessed it!—our beloved interfaces construct:
Many object-oriented languages have some notion of interfaces, but what makes Go’s interfaces so distinctive is that they are satisfied implicitly. In other words, there’s no need to declare all the interfaces that a given concrete type satisfies; simply possessing the necessary methods is enough. This design lets you create new interfaces that are satisfied by existing concrete types without changing the existing types, which is particularly useful for types defined in packages that you don’t control.
~ Alan A. A. Donovan, Brian W. Kernighan (The Go Programming Language — Addison-Wesley)
How cool is that? ๐Ÿ˜Ž

Noted Go programmer Lex Sheehan has aptly remarked in his fine book on bringing the functional programming paradigm to the practice of Go—yep, this is where the "Paradise Regained" subtitle above comes in—by leaning on the inimitable uniqueness that Go's design brings in its wake, which is, frankly, a cornucopia of (design and implementation) possibilities that were simply not possible before it arrived on the scene:
When I discovered Go, it was like paradise regained; A return to simplicity with added benefits of concurrency, networking, great development tools, first class functions as well as the best parts of OOP.
~ Lex Sheehan (Learning Functional Programming in Go — Packt Publishing)
One more time, just how cool is that? ๐Ÿ˜Ž

4. Of Object-orientation And The Platypus ๐ŸŒ


Oohh… ๐Ÿ˜ฒ

And what do we have on our hands now? Readers are like: Whoa, are we getting into the platypus metaphor with which early adopters of object-orientated programming got indoctrinated (more like pummeled)? Akram, Akram, we know you all right, so don’t you even think of pulling a fast one on us! ๐ŸŽƒ

Okay, relax, here's all that's going on, as we find ourselves being enlightened by Tim Budd, a fine and upright professor of Computer Science at Oregon State University:

Imagine a big old class hierarchy—yep, one of those sprawling ones that seem to invariably inhabit the land of object-orientation—that includes people, mammals, and, most of all, Phillip the platypus who lives at the zoo ๐ŸŠ ๐Ÿ„ ๐Ÿป ๐Ÿผ ๐Ÿธ ๐Ÿซ ๐Ÿƒ ๐ŸŽ ๐Ÿ ๐ŸŒ
Well, Phillip the platypus presents a problem for our simple organizing structure. I clearly know that mammals give birth to live children, for example, and Phillip is certainly a Mammal, and yet Phillip (or rather his mate, Phyllis) continues to lay eggs ๐Ÿฃ

To accommodate this, we need a technique to encode exceptions to a general rule. We do this by decreeing that information contained in a subclass can override information inherited from a parent class ๐Ÿ‘ช

Most often, implementations of this approach takes the form of a method in a subclass having the same name as a method in the parent class, combined with a rule for how the search for a method to match a specific message is… ๐Ÿ‘€
Stop already!!! ๐Ÿ˜ฑ

Hey, relax, I was just trying to make a point that human cognition, more precisely how much we can keep in our head at any given time without losing track—anyone up for a slight detour into the intrigues of the mental construct that psychologists glibly refer to as "working memory"?—and the ways in which certain programming constructs and paradigms can tax that ability (of "working memory", that is) ๐Ÿ™‰

Enter the Go programming language in all its unadorned simplicity and sheer power… ๐Ÿ’ช

5. Calming Down To The Soothing Rhythm Of… Unit Testing! ⛵


In his best efforts to get the readers all calmed down (after that nerve-wracking brush with Phillip the platypus showing up in the inheritance hierarchy), the programmer has everyone sit around—you guessed it—his (not round, but rectangular) programming table. Then, asking everyone to take 10 deep breaths, he deftly pulls out his copy of the canonical Go book. Needless to say, the mere sight of the book's tasteful cover has a remarkably soothing effect on the jangled nerves of the ragtag group ๐Ÿ˜ป

On top of that, no sooner does our programmer plunk down his copy of The Tao of Microservices—its cover adorned by an illustration of the benevolently meditating beatific Emperor Reigen of Japan, the 112th emperor of Japan—than there is hushed silence. Time for yoga, everybody! ๐Ÿ’

Wait, yoga can wait… First, though, we're going to chat a bit about—you guessed it—unit testing. After all, it all starts with testing—unit testing that is—so let’s go there… ๐Ÿš•

As noted Go programmer Mat Ryer rightly notes in his online post on 5 simple tips and tricks for writing unit tests in #golang:
Test-driven development is a great way to keep the quality of your code high, while protecting yourself from regression and proving to yourself and others that your code does what it is supposed to.
You owe it to yourself—as do I—to check out the word on unit testing, straight from the horse's mouth ๐ŸŽ

One more pointer while we're on the topic of unit testing in Go: We can ideally put unit tests in the service of teasing apart design decisions themselves! For the very best on that, I do not know of a better resource than this one: Growing Object-Oriented Software, Guided by Tests (by Steve Freeman and Nat Pryce — Addison-Wesley Professional)

(It’s example code is heavily in Java, but the ideas are universal and timeless) ⏳

6. If You Fall, I Will Catch You, I'll Be Waiting ⚾


Ah, nothing like having a safety net to catch us when we fall, time after time—hey now, catching and hauling in some fish isn’t too bad either (I’ll confess that those tilapia taste the best, if that's what those fishermen are hauling in!) ๐Ÿก

Yo, but what about my tidy inheritance hierarchies with objects all neatly nestled in their cozy containers? Glad you asked, because that’s where we go next ๐Ÿ“ฆ ๐Ÿ“ฆ ๐Ÿ“ฆ ๐Ÿ“ฆ ๐Ÿ“ฆ ๐Ÿ“ฆ

7. Whew, Sprawling Hierarchies No More ๐Ÿšง

Great things are not done by impulse, but by a series of small things brought together.
~ Vincent van Gogh (the one and only Dutch Post-Impressionist painter)
Loved that van Gogh quote, because it goes our way, the Go way—no, no, no, not Go away! I said the Go way, so you stay right there! ๐Ÿ„

I mean, what's there to not love about the philosophy of achieving great things—including the creation of great designs in software—through "a series of small things brought together"? I will go out on a limb and say that this is the whole Go philosophy: Composition is king ๐Ÿ‘‘

See those tidy little organic cups in the pic above, fungal spores or whatever they are? Dare I ask, Do you find yourself re-creating equally, um, intricate hierarchies in your software designs and feel at times like tearing your hear out? Well… I think that it's high time for us to revisit (and do something about the implications of) our assumptions about what flies—and what doesn't—in the multi-core world which we now inhabit.

Yep, it's no coincidence that functional programming has taken off in our industry ๐Ÿš€

I've already written at length on this topic, so here I will merely point you in the direction of a couple of resources that will help you:
Wait a second, did I hear an owl hooting? ๐ŸŒฒ
There was an Old Man with a beard,
Who said: “It is just as I feared!
Two owls and a hen,
Four larks and a wren
Have all built their nests in my beard.
~ Edward Lear (from his Book of Nonsense)
We really need to check out what's going on… ๐ŸŽฌ

8. Go, Your Own Way ๐Ÿ„


Actually, speaking of owls…

Groan, we need more coffee, you all say. And I'm like, does this place look like a Starbucks or something? We are all morning larks here; sorry, all you owls out there ๐Ÿฃ

A word to the wise, in somewhat sheepishly pointing out the criticality of where the "comma" is placed, or not—as in there "Go, Your Own Way" or as it's missing here in "Go Your Own Way"—we get totally different outcomes. Shall I elaborate, or will I be, heavens forbid, questioning your fine intelligence? ๐ŸŽ“

But first, what's going on here? We… We hear these refrains ๐ŸŽผ
I have climbed highest mountain
I have run through the fields
Only to be with you
Only to be with you
~ U2 (Lyrics from I Still Haven't Found What I'm Looking For)
And then these, soon thereafter ๐ŸŽถ
I'd drive a thousand miles
Haul a trailer of tears
Just to see you smile
And as the dawn appears
At the edge of the night
There's still a light that gleams
Beyond my wildest dreams
~ Mark Knopfler and Emmylou Harris (Lyrics from Beyond My Wildest Dreams)
So here's the deal: See that sleepy owl up there? Try getting him to waddle out of his nest, let alone have him climb the highest mountain or—this is even more outlandish—run through the fields ๐Ÿƒ

And as for this sleep-deprived owl driving a thousand miles—that's Mark Knopfler and Emmylou Harris who appear elsewhere in another essay—sheesh, let's not even go there!

Actually, now that I think about it, with the era of self-driving cars dawning upon us, we could have our owl simply sit behind the steering wheel (more like perched on it!) in a car and be chauffeured a thousand miles ๐Ÿš•

That would do it: Hey, now how about that?

Where I was going with all that was simply this: I have a hunch that the Go programming language will come to play one role or another in helping make self-driving cars in reality.

But I digress๐Ÿšถ

9. The Widening Gyre Of Concurrency ๐Ÿš…

Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere anarchy is loosed upon the world.

~ William Butler Yeats (from his inimitable poem The Second Coming)
Tell you what, let’s all collectively digress before resuming our adventure in earnest: And what could be better than regaling in a marvelous poem or two by W H Auden?
A sentence uttered makes a world appear
Where all things happen as it says they do;
We doubt the speaker, not the tongue we hear:
Words have no word for words that are not true
๐ŸŽญ
~ W. H. Auden
What?! "I’d rather listen to Eminem," you say … (Sigh, you can't win 'em all) ๐ŸŽท

As noted Go programmer Katherine Cox-Buday has cogently argued in her fine book entitled Concurrency in Go: Tools and Techniques for Developers (O'Reilly Media), the key thing to keep in mind is that
…cloud computing also presented many new challenges. Provisioning these resources, communicating between machine instances, and aggregating and storing the results all became problems to solve. But among the most difficult was figuring out how to model code concurrently. The fact that pieces of your solution could be running on disparate machines exacerbated some of the issues commonly faced when modeling a problem concurrently. Successfully solving these issues soon led to a new type of brand for software, web scale.
Yep, hence my reference (in the subtitle above) to "The Widening Gyre Of Concurrency" ๐ŸŽฏ

(And hey, to all of you who didn't immediately write me off for using that seemingly fanciful subtitle, I thank you for placing your trust in me!)

10. Go's Got Concurrency ๐Ÿ‘ป


Okay, so here is the programmer’s best effort to convey the essence of concurrency—in Go or, for that matter, in any other programming language you care to name (Provided, of course, that the given language has support for concurrency. I mean, concurrent FORTRAN? Gimme a break) ๐Ÿ™‰

For the final word on how to approach concurrency during the practice of Go  programming, I refer you again to
Concurrency in Go: Tools and Techniques for Developers (O'Reilly Media) by Katherine Cox-Buday
Don't miss Katherine's fine book—immensely readable; simply invaluable ๐Ÿ‘

11. Bringing Go To The IoT World ๐Ÿ™


You knew that the octopus—more like the octopi as in the pic above—with whose tentacles we had a close brush earlier was going to pop up (again) unannounced, anytime. And so it is that you're going to find an octopus sprawling about in the background of the homepage for this incredible open-source project whose latest version is based on a Go implementation:
EdgeX Foundry™: The Open Interop Platform for the IoT Edge
It's essentially a vendor-neutral open source project building a common open framework for IoT edge computing (It's hosted by The Linux Foundation, and I happen to be a committer) ๐Ÿ”จ

Here's the scoop—meanwhile I just caught myself drifting to visions of Baskin-Robbins ice cream scoops there for a few moments!—lifted straight from the EdgeX home page, a place where you can find plenty of other cool details as well ๐Ÿฆ
At the heart of the project is an interoperability framework hosted within a full hardware- and OS-agnostic reference software platform to enable an ecosystem of plug-and-play components that unifies the marketplace and accelerates the deployment of IoT solutions.
One more thing—Check out an intriguing take on exactly why it is that an octopus was chosen for branding the EdgeX project ๐Ÿ™
I’m also excited about the branding for EdgeX Foundry, which, in the great tradition of the Linux penguin, the Docker whale and other open source projects, features a “spirit” animal, namely an octopus. Why? Simple. Aside from being wickedly cool to look at and one seriously well adapted creature, the octopus is a living, “breathing” example of edge computing.
Here’s what I mean: every octopus has not one brain, not two, not three or even four, but nine brains total, one in each tentacle and a central brain in the head. Suction cups act as sensors that feed “data” into the tentacles’ brains, which are coordinated (to the best of researchers’ knowledge) by the central brain in the octopus’ head. That’s a lot like a distributed analytics architecture stretching from the edge to the fog to the cloud—and exactly what IoT and EdgeX Foundry are all about!
And since we are speaking of the highly evolved animal kingdom, let's check out what's up with another member of the kingdom, our feathered friend in the pic coming right up ๐Ÿ

12. Persistence In Go ๐Ÿ’ฐ


You’ve got to doggedly keep at it. Persistence—no, not that kind of persistence—is the name of the game when it comes to grokking the Go programming paradigm. I mean, just check out that bird gnawing away at a… bicycle seat, goodness gracious! Yo, bird, you don’t have to be that destructive either! How much nutrition does that bicycles offer, for crying out loud? (This coming from a diet-conscious, nutritionally-aware programmer) ๐Ÿ” ๐Ÿ• ๐ŸŸ ๐Ÿฐ ๐Ÿญ ๐Ÿฉ ๐Ÿช

My thinking in this area—as it applies to Go—is currently evolving. Yep, you guessed it: this section is under heavy construction until further notice ๐Ÿšง

As a prelude (to the heavy construction underway), though, I won't stop you from checking out the following two engaging resources
Enjoy ๐Ÿ™Œ


13. Go Can Be Sweet ๐Ÿฏ

This is how sweet and free of fear
I feel now in myself. Beyond opinion and judgment, undistracted by guilt,
I am walking strong and steadily home,
not timid or uncertain,
with my eyes splendidly clear,
all one pearl of gratefulness, no fear.
~ Jelaluddin Rumi (in the translation by Coleman Barks entitled The Essential Rumi — Published by HarperOne) 
I knew it, I just knew it: One of you smart Alecs (or Alexas) out there can—at this very moment—barely restrain herself from pointing out our programmer’s, shall we say, propensity for doughnut consumption (I am on my knees here, begging you to please not check out my ramblings on Kafka at the preceding coordinates) ๐Ÿ˜ฐ

But we’ve got you covered; just check out the M&M bounty above (And no, this has nothing to do with Eminem, okay? I've already had enough with people not warming up to the loveliness that is the poetry of the one and only W H Auden: Dare I add that, yes, you're right, this essay is semi—autobiographical, so there!) ๐ŸŽญ

And yes, Go can be sweet ๐ŸŒน

14. Go Can Be Baffling (To The Uninitiated) ๐Ÿ˜ฑ


What in the world—actually more like, what on the branch—is that? Is that a bird of paradise or something? I dunno. Do I look like an ornithologist? But with its head gingerly tilted to one side, it sure looks baffled ๐Ÿ

Anyhow, once you get the lay of the land of Go—for example the notion that the package is the unit of encapsulation or the philosophy to share by communicating instead of communicating by sharing—programming in Go can be dead simple ๐Ÿ’€

No more bafflement, I say: I recommend that you check out this fine resource ๐Ÿ’ฐ

15. Let Beautiful Designs Emerge ๐ŸŒน

Simple can be harder than complex; you have to work hard to get your thinking clean to make it simple.
~ Steve Jobs
Beautiful designs will emerge invariably from simplicity, and not from deeply nested—read deeply convoluted—hierarchies of objects ๐Ÿ’ 

16. What About Recursion? ๐ŸŒ€


Yes, what about it? ๐Ÿ˜‰

A bit exhausted from all this intense talk, we decide to take a break from our adventure: We head for that inviting sofa in the corner. But, wait a second, the impish octopus—and the two gophers—are still in close pursuit of us. Sheesh, can’t seem to shake them loose, dude!

All is not lost, though: Check out that enterprising Matryoshka doll standing upright, and that, too, right next to the glorious bash logo (Man, this doll’s got style, and good taste, I’m telling you!) ๐Ÿ„

Barely have we finished sizing up the situation than we spy some shrubbery ambling down the banister just above the sofa… ๐ŸŒฟ

Oh my, this is no time for taking a breather. I know, I know—I hear you say— just tell that to the dreamy, porcelain-encrusted dude in the pic below! ๐Ÿ˜ด He's either in a ruminating reverie or else thinking deep thoughts on concurrent design solutions (in the Go programming language of course).

My thinking in this area—as it applies to Go—is currently evolving. Yep, you guessed it: this section is under heavy construction until further notice ๐Ÿšง

17. Things Explainer: You're Kidding Me, Right? ๐Ÿ“ฃ


What we really need is someone to make sense of all this, and explain away in simple terms: You guessed it, Things Explainer to the rescue. Imagine...

So let’s turn to exactly that, which is coming up by way of the next pic...

This section, meanwhile, is under heavy construction until further notice ๐Ÿšง

18. Things Explainer: Redux ๐Ÿ“•

Explaining Metaphysics to the nation–
I wish he would explain his Explanation
๐Ÿ˜‰
~ Lord Byron (from Don Juan: Dedication)
But what, you ask, is that DVD—is that really Out of Africa?—doing there, jostling cheek to jowl with our trusty Things Explainer. Once again, glad you asked...

As it turns out, this section, too, is under heavy construction until further notice ๐Ÿšง  

19. Go Forth And Smell The Roses ๐ŸŒน ๐ŸŒน ๐ŸŒน ๐ŸŒน

Every rose has its thorn
Just like every night has its dawn
Just like every cowboy sings his sad, sad song
Every rose has its thorn
~ Poison (Lyrics from Every Rose Has Its Thorn)
So here we are in the end, smelling like roses; see, didn't I tell you, this was going to be an adventure with a happy ending? But you haven’t yet talked about some of the more intricate aspects of Go, I hear you say. And right you are (as always, I tell myself, over and over again, that the customer—you, dear reader—is king), because around here, you get to call the shots, now and forever ๐ŸŽฏ

That’s my stance anyway. So there.

Speaking of roses—and yes, every rose has its thorn—a thorn had been gnawing at my side: Anyone recall the conversation, apocryphal or not, at the outset when we had found ourselves eavesdropping on a lively dialog involving a recalcitrant reader and yours truly? Maybe it was just a pipe dream after all ๐Ÿ’ธ

Yo, why would I make such an assertion like that? Here's why, it's readers like you who keep me going—an Energizer Bunny I am not, so I, too, need some motivation from time to time:
You can't start a fire sitting 'round crying over a broken heart
This gun's for hire
Even if we're just dancing in the dark
You can't start a fire worrying about your little world falling apart
This gun's for hire

~ Bruce Springsteen (Lyrics from Dancing In The Dark)
Yep, comments such as this one (from a couple of days ago) and these ones (from many more moons ago) start my fire ๐ŸŽ‰ ๐ŸŒ‹ ๐Ÿ”ฅ

You're the best, thank you! ๐Ÿ’Ž

20. Deep, Yet Simple ๐Ÿณ


That's how I'm finding Go to be. To put that into, context, check out this quote—Oh, I love this quote ๐Ÿ’
You are lucky you have such a deep interest in nature, and even if you find it is much more complicated and difficult to understand than you thought, when you learn more about it, it is also in certain ways more simple and beautiful than what you can imagine.
~ Feynman, Richard P. Letter to student Charles E. Tucker, April 1967 (from The Quotable Feynman — Princeton University Press)
And who shall have the last word: Me (your unceremoniously casual writer) or the Go gopher (check out the tuxedoed Go gopher in the pic below, his hair all combed-back slick like Johhny Depp, with gobs of da real thang, that LA Looks hair-stylin’ gel) ๐Ÿ€

Look, I don’t stand a chance against that dude, not even if I pull out my best gangsta sentences... When it comes to competing with the mighty Go gopher, I’m already sober, reminding myself as I do of the sage advice that๐Ÿ‘บ
If at first you don’t succeed, try, try again. Then quit. There’s no use being a damn fool about it.
Your honor, I rest my case ๐Ÿ’ผ

Monday, May 28, 2018

Domain-Driven Design (DDD) Defies Dogma

1 b
Domain-Driven Design: DDD is a process that aligns your code with the reality of your problem domain. As your product evolves, adding new features becomes as easy as it was in the good old days of greenfield development. Although DDD understands the need for software patterns, principles, methodologies, and frameworks, it values developers and domain experts working together to understand domain concepts, policies, and logic equally. With a greater knowledge of the problem domain and a synergy with the business, developers are more likely to build software that is more readable and easier to adapt for future enhancement.
~ Scott Millett and Nick Tune (Patterns, Principles, and Practices of Domain-Driven Design — Wrox Publishers)

Prelude ๐Ÿ„

See that Tower of Babel in the picture above? Okay, so the Babel Fish was one thing—especially for you all fans of Douglas Adams’ book The Hitchhikers Guide To The Galaxy—and the Tower of Babel quite another, with the latter being the one we’re talking about here (Let me guess: The first thing that came to your mind at the mention of the Tower of Babel was the clamor arising from throngs of people in a collective din, clamoring past one other as they all speak in their own distinct languages, past others’ monologues in their languages!) ๐ŸŽช

But before we get sucked into the Babel vortex—look, it could have been a whole different
vortex that we as a society could've gotten pulled into (actually, already is, the inexorable digital vortex, that is)—let’s all of us take a big, deep breath ๐Ÿณ

Dedication ⛳

My regular readers are of course well aware that it's only the rarest of occasion and time when I dedicate an essay or two to an individual; this is such an occasion, and this is such a time. With that, I dedicate this essay to Githesh Ramamurthy who is one of the clearest-eyed leaders, embodying what it means to lead by example: He leads with integrity, intelligence, wit, passion, and grace. Githesh is a mentor, benefactor, and friend ☕

Whenever you read these words—and I know that you've always carved time out of your super-busy schedule to read what I offer on this blog—please know that your encouragement, plus the priceless lessons that I’ve learned from you, Githesh, will serve me well for a lifetime, especially so at this juncture as I prepare for the quest to help change the world of the Internet of Things (IoT) as we know it today! ๐Ÿ”ฎ
2 b

Preamble (By Way Of A Dialogue) ⛱

—Reader: Hey Akram, so whatever this DDD (Domain-Driven Design) thing is anyway, we're willing to give it a listen. But what—more properly, “who"—in the world is this “Dogma” that you mention in the same breath as the title of this essay: "Domain-Driven Design (DDD) Defies Dogma"? ๐Ÿถ
—Akram: Um, so the “Dogma” part of the story goes something like this: Being the inveterate cat-lover that you all know me as, I nevertheless once took pity on and gave shelter to a dog whose Ma was somewhat indisposed. So this dog’s Ma, as I was saying… ๐Ÿ˜ณ
—Reader: Yo, stop. Stop right there! Heaven help us, Akram, lest you take it upon yourself to start spinning yarns again. (Dude, we are still licking our wounds after being exposed to your balderdash—that wasn't so long ago either—having to do with your recursive take on Reveling In The Glory Of Software (On A Stormy Night!)) ๐Ÿ‘บ
—Akram: May I inform your gentle ears that the name—Programming Digressions but of course—of our blog site may have something to do with digressing. But hey, we will digress no more! Instead, we'll dive headfirst into the coolness of DDD. Cool? ๐Ÿ˜Ž
—Reader: We’ll believe that when we see it. But yeah, go ahead… ๐Ÿšง
7 b

1. Outside, Looking In ๐Ÿ”ญ

Would you rather be outside, looking in—like the little girl peering through the glass window at the intriguing rodents in a section of the zoo—or instead partake in the grand design, taking a cue from Mother Nature? If you answered yes, and if you’re up for it, let’s you and I follow the road on a quest to find out a particularly powerful software design approach that should not be allowed to languish anymore… ๐Ÿš•

But first, FWIW, allow me to—and this is especially for those of you who are already looking for me to make things snappy—introduce three sparkling books (including the seminal one which started it all) which capture the aforementioned software design approach that we will be grappling with over the course of this essay:
  1. Implementing Domain-Driven Design — Addison-Wesley Professional (by Vaughn Vernon)  
  2. Patterns, Principles, and Practices of Domain-Driven Design — Wrox Publishers (by  Scott Millett and Nick Tune)
  3. Domain-Driven Design: Tackling Complexity in the Heart of Software — Addison-Wesley Professional (by Eric Evans)
Each one of the books in the list above is stellar in its own right; ignore it at your own peril (just sayin’.) Curiously enough—referring here to the fine book by Vaughn Vernon—there is a lot of cowboy humor liberally sprinkled throughout the pages of his book, Implementing Domain-Driven Design. Overall, though, it’s a book worth reading: So if riding horses isn't exactly your thing, please don’t let that blemish your view of a superb book! ๐ŸŽ

FWIW, I’m going to quickly add that the same author (Vaughn Vernon) went on to write an even more awesome book called. More details—even more than you might care for!—on exactly that can be found in an essay elsewhere: Best Reactive Programming Books.

With that… Whoa, what do we have here but a cowboy—and a petrified one at that—surrounded by crisp prairie grass, looking intently at the paradoxical downtown buildings over yonder… ๐ŸŒพ

Something really, really anachronistic is going on here, methinks ⏳
8 b

2. Doing DDD—Until The Cows Come Home! ๐Ÿ„

Here, then, is the real deal (cowboy humor and all) when you are ready to dive into the implementation details of Domain-Driven Design (DDD). But I hear you asking, Yo, how does this all defy dogma? ๐Ÿถ

And to which I can only reply—at this time anyway—with the admonishment to please, Hold your horses! Everything comes in its own good time, and for especially those who wait!
As my life goes on I believe
Somehow something's changed
Something deep inside
Ooh a part of me
There's a strange new light in my eyes
Things I've never known
Changin' my life
Changin' me
I've been searchin'
So long
To find an answer
...
Good things
In life
Take a long time
yeah yeah

~ Chicago (Lyrics from (I've Been) Searchin' So Long)
Dogmatism aside, imagine this: Would you rather learn things through rote memorization or via discovery? Where would we be today—as a society whose fabric has been woven through vast infrastructures of inter-networking— had we settled for the de jure standard (the OSI layered model) instead of the far superior de facto standard (TCP/IP networking)? ๐Ÿ“ฌ
23 b

3. Who Is The Best Designer Of Them All? ๐Ÿ“

Wait a second, Akram, are we going hunting for mushrooms—or toadstools or whatever in the world those three bright-red spotted things growing on stalks are—just as we had settled down with a mug of coffee in hand?! ๐Ÿ„

Sigh, me and my grand designs: All I was trying to do there was to bring to the forefront of your mind the organically evolving designs sprinkled by Mother Nature across the length and breadth of the natural landscapes around us…
3 b

4. Organically Evolving (Software) Designs ๐Ÿ’

All the same—my grand and outlandish schemes notwithstanding—the oh-so organic evolution outgrowth of those toadstools provides us with a perfect segue into the wherewithal of DDD! And here we are going to hear from the horse's mouth (Okay, so Eric Evans is a fine human being, and an excellent one at that; I am merely using the proverbial dictum about the apocryphal horse's mouth.) Yep, Evans is the guy who started it all: DDD as we know it today was ushered into the world through his creative agency. ๐Ÿ†

And you don’t have to take my word for it—listen to some luminaries of our industry gushing about his work:
If you don’t think you are getting value from your investment in object-oriented programming, this book will tell you what you’ve forgotten to do.
~ Ward Cunningham
 
This book belongs on the shelf of every thoughtful software developer.
~ Kent Beck
To those rave reviews I’ll add Evans’ succinct round-up of the gestalt of DDD:
I have spent the past decade developing complex systems in several business and technical domains. In my work, I have tried best practices in design and development process as they have emerged from the leaders in object-oriented development. Some of my projects were very successful; a few failed. A feature common to the successes was a rich domain model that evolved through iterations of design and became part of the fabric of the project. 
This book provides a framework for making design decisions and a technical vocabulary for discussing domain design. It is a synthesis of widely accepted best practices along with my own insights and experiences. Software development teams facing complex domains can use this framework to approach domain-driven design systematically.
Yep, right there in the pic below is my copy of Evans’ book, surreptitiously propped up against a hefty tome that you should also check out sometime, probably sooner than later, especially if you’re into AI that sort of thing. It's a rather tastefully designed book: Planning Algorithms (Cambridge University Press) by Steven M. LaValle ๐Ÿ‘ป
21 b

5. Ships Laden With (Docker) Containers ๐Ÿšข

Wait a second, what in the world is that container-laden ship doing here? Docker containers anyone? Anyone?! (Just sayin’, just sayin’ because I'd rather stay rooted in the physical realization of building systems versus some ivory tower stuff, and I’m not even talking about Eiffel the tower or yo, for that matter, Eiffel the programming language!) ๐Ÿ—ผ

But I digress ⛷
4 b

6. The Crimson-braided Book ๐Ÿ“•

I love this book, tastefully crimson-braided, standing upright, bolstered at the back by the same book (Planning Algorithms from the Cambridge University Press) that we ran into earlier, of course: Patterns, Principles, and Practices of Domain-Driven Design by  Scott Millett and Nick Tune is in a league of its own when it comes to imparting the wisdom in the DDD territory.

This is one of those rare, stellar software books where it's evident that great care and attention was lavished in preparing it. Profusely illustrated, clearly articulated, replete with marvelous end-of-chapter summaries, this book is a keeper. I'm a Go/Java/Scala programmer, and have been working in the Big Data area for a while, and would have preferred the code examples to be in either of these languages. But I must confess that the C# code is pristine enough in its quality that it it's easy to follow along ⛵

The content and crystal-clear presentation is abundantly evident throughout, though I feel compelled to point out two stand-out chapters that are not to be missed:
  • Chapter 21: RepositoriesRepositories mediate between the domain model and the underlying data model. They ensure that the domain model is kept separate from any infrastructure concerns.
  • Chapter 24: CQRS: An Architecture of a Bounded ContextCQRS is a design pattern that creates two models where there once was one. Instead of a single model to handle the two different contexts of reads and writes, two explicit models are created to handle commands or serve queries for reports.
All-in-all, a terrific and delightful book, which is why I think of it as one of the two definitive DDD books, the other one being, of course, the seminal volume by Eric Evans himself (the classic book entitled Domain-Driven Design: Tackling Complexity in the Heart of Software)! ๐Ÿ’˜
22 b

7. Representations Are Ubiquitous. And Yes, Representations Do Matter ๐ŸŽญ

OK, Akram, isn’t it about time that you stopped rambling—we know all too well that you are a sucker for (great) books and stuff—and instead gave us the scoop on the guts of DDD for crying out loud? So it’s Akram here, saying merely this much in my defense that the deal goes like this: While DDD is not going to solve weighty issues which humanity faces—the mosaic in the picture below with love and harmony and peace suffused all over is an ideal to which we should all strive nonetheless—anytime soon, it’s only fair to mention that the way it (DDD) entered my lexicon will necessarily have us take a trip back to the time. That’s when I was working as a senior software engineer for Boston Scientific (not in Boston, mind you, but in the good old Twin Cities in my beloved Minnesota) and I noticed  a copy of Evans’ groundbreaking book sitting on the desk of one of my coworkers… ๐Ÿ“š

My (now-erstwhile) coworker began talking about this thing called a Ubiquitous Language and stuff like that. It made some sense at that time, and I actually headed over to the local Barnes & Noble that afternoon and got myself a copy of the book; the booksellers  there, of course, all knew me by first name, and on seeing me enter the bookstore, realized full well that I must have found yet another excuse for buying yet another book (But they weren’t complaining, at least as best as I could tell.)

The bottom line is this: Representation does matter—Would you rather work with concise JSON-encoded representations of data or with their far more verbose kin, those XML-encoded representations? Would you rather do arithmetic using the lean and efficient Arabic numerals or their laborious kin, the Roman numerals? Yep, I thought you would agree ๐ŸŒ‚
6 b

8. Fast-forwarding By 10 Years ๐Ÿš‚

That was 10 years ago. Let’s fast-forward to 2018—and one more time recycling a pic that appeared above moment ago—and you have the best book published on the subject of DDD: Patterns, Principles, and Practices of Domain-Driven Design by  Scott Millett and Nick Tune can serve as a model for the best that there is in the presentation of technical material! ๐Ÿฐ
22 b

9. Principled Design Must Be Informed By A Ubiquitous Language ๐Ÿ™‹

Ah yes, so I was going to give you the lowdown on the essence of DDD. It’s a mindset of principled design which expects of us—the technology types—to level with the domain experts and treat them as equal partners in an approach to the design and crafting of software that is informed by a shared language (Yep, you guessed it: We’re talking about the Ubiquitous Language here!) ๐Ÿ‘

To take the bird’s eye view, we—collectively the domain experts (the SMEs) and the technology types—should remove the artificially-erected barriers in our communication and instead work hand-in-hand to accomplish more in less time ๐Ÿ‘
9 b

10. Oh, The Fun We're Going To Have! ๐Ÿ‘ง

Oh my, and and I would tell you about the fun we’re going to have along the way! Pure, unadulterated joy is not far off. Not far at all, in fact, provided that we jettison off the arcane approaches of yesteryear… ๐Ÿš›
10 b

11. Did Someone Say… Refactor? ๐ŸŽฏ

Wait, did somebody say something about refactoring those lumbering engines like those which appear in the pic below? Oh my, I’d rather stick to refactoring my code, with the help, of course, of DDD tactics and strategies. After all, DDD is squarely about brainstorming that's informed all the while by collaborative learning ๐ŸŽช

Actually, I’m going to take one step back—from my mention above of refactoring code—and talk some about refactoring design itself. I mean, are you able to sit down with paper and pencil (or stand in front of a whiteboard for that matter) and come up with a useful model right away? If you can, then you're likely in the same league as Leonardo da Vinci, and I ceremoniously—insert one drum-roll here—refer you to the following two essays:
Meanwhile, for us mere mortals, as we grapple with initial design models in the quest to refactor and evolve those models, it would serve us well if only we appreciated more that the model and the language (used to describe any given model) are not static entities; if not attended to properly, the the model and the language can easily devolve into a Big Ball Of Mud. Hey, nobody wants that! ๐Ÿ

So the lesson to draw here is: As software practitioners, not only should we tend to mercilessly refactoring our code, we should pay at least as much attention—if not more—to refactoring our software design.
11 b

12. Then There Was The Repository ๐ŸŽ

Speaking of DDD tactics and strategies, allow me to introduce another DDD concept—a centrally important one at that—which deals with the notion of a Repository. See those steely-faced gents carved into Mount Rushmore as in the picture below? There you go. And look, I’m not trying to be cute here: Evan’s himself—in the picture which adorns the beginning of the central chapter dealing with Repositories—presents the image of a steely faced librarian zealously guarding a bookshelf worth of books ๐Ÿ’‚

Crucially, he notes:
The goal of domain-driven design is to create better software by focusing on a model of the domain rather than the technology. By the time a developer has constructed an SQL query, passed it to a query service in the infrastructure layer, obtained a result set of table rows, pulled the necessary information out, and passed it to a constructor or FACTORY, the model focus is gone. It becomes natural to think of the objects as containers for the data that the queries provide, and the whole design shifts toward a data-processing style. The details of the technology vary, but the problem remains that the client is dealing with technology, rather than model concepts.
~ Eric Evans (in Domain-Driven Design: Tackling Complexity in the Heart of Software — Addison-Wesley)
 
To cut a long story short—woohoo, no digressions for a change—pay special attention to the crucial role that repositories play in the practice of DDD ๐Ÿ‘€
13 b

13. I Want To Fly Like An Eagle (Or, Failing That, Like A Seagull) ๐Ÿฌ

Once you got that down—plus a few salient concepts such as Bounded Context, Domain Event, and Aggregate— you will surely feel the unbearable lightness of unencumbered, yet disciplined, design. Indeed, you are bound to identify with the seagull soaring above the ocean waves as in the picture below ๐ŸŒŠ
I want to fly like an eagle
To the sea
Fly like an eagle
Let my spirit carry me
I want to fly like an eagle
Till I'm free
Fly through the revolution

~ The Steve Miller Band (Lyrics from Fly Like An Eagle)
—Reader: Wait a sec! Are we talking seagulls or eagles or what? Can we at least get that right please?
—Akram: Sheesh, some people can be, like, so picky! No matter what, remember, though that

Time keeps on slippin', slippin', slippin'
Into the future
Time keeps on slippin', slippin', slippin'
Into the future

~ Also by The Steve Miller Band (Lyrics from Fly Like An Eagle)

All good? Ready to proceed and meet even more interesting characters in our meandering DDD journey? ๐ŸŽก
12 b

14. Of Meandering Neanderthals ๐Ÿ—ฟ

Hoh, hoh, hoh, did somebody just say something about “…meandering journeys”? Okay, this is a bit too much to resist, and I simply can’t bring myself to close out this essay without sharing some wisdom—something that could demonstrably have been garnered only by someone deep into the cavernous and meandering landscape of distributed software systems design—which is, oddly enough, by way of a riddle that spontaneously arose in my mind during the past 24 hours. It goes like this ๐Ÿ™Š
Question: What do you call a Neanderthal who is prone to meandering?
Answer: A Meanderthal, but of course!
So there. Now you tell me if the connection (Nexus?) of this parable-laden wisdom to the meandering landscape of distributed software systems design isn’t as clear as the day? Yes, yes?! ๐Ÿ’ค

Whoa, is that a Meanderthal—tastefully attired in that oh-so demure costume or something—in the pic below or what? I mean, wow, for one thing, it’s sure got a bevy of enthralled kids for its audience! ๐Ÿ‘ง ๐Ÿ‘ฆ
14 b

15. Lightsaber-wielding Goslings Sure Can Derail The Practice Of DDD ๐Ÿ”จ

But no sooner had we soothed our nerves than we took a few steps in the star-board direction and came across a fierce creature as in the picture below! Exactly, didn’t I tell you? Here be monsters!! All that this gosling—and no, it’s not related in any way to mild-mannered James Gosling, the original and primary designer of the Java programming language—is missing is a Jedi lightsaber, and we are out of here, like, pronto! ๐Ÿ”ช


Look, here’s the deal: To practice DDD with any level of focus, we need uninterrupted quanta of concentration. We’d rather not be dealing with Jedi lightsaber-wielding goslings if we are to get anywhere with designing software that is going to power the new era that is dawning… ๐ŸŒž
15 b

16. Our Ships Sail Into The Harbor ๐Ÿšฃ

Finally, we witness how the ships have sailed onto the shore, or at least some boats have! See those trawlers and fishermen hauling in their nets after a hard day’s work of the disciplined practice of DDD? Yep, it’s Entities and Aggregates all the way down…

Dare I say that our friends the turtles may wish to have a word or two with us in this regard… ๐Ÿข
16 b

17. Bright, Colorful Designs ⛄

Last, but certainly not least, you may find yourself perking up at the site of the motley crew, ragtag band of mailboxes lining a lazy street

Honestly, answer me this: If people would only get a little creative in choosing colors for their mailboxes, wouldn't life itself become all that more colorful? ๐Ÿ“ช ๐Ÿ“ซ ๐Ÿ“ฌ ๐Ÿ“ญ ๐Ÿ“ฎ
18 b

18. Let's Not Forget About CQRS! ๐Ÿ˜

Don't you forget about me
Don’t, don’t, don’t, don’t…
Don't you forget about me

~ Simple Minds (Lyrics from Don't You (Forget About Me))
As we wind down this essay, it behooves us to remain mindful of yet another player in the DDD solution space: CQRS (Command Query Responsibility Segregation). I strongly encourage you to check out the marvelous narrative on CQRS—truly one of the standout sections—in the remarkable book named Patterns, Principles, and Practices of Domain-Driven Design (Wrox Publishers, by Scott Millett and Nick Tune) ๐Ÿš€

In particular, they introduce the reader to the notion of CQRS without any fuss by elegantly clarifying that CQRS
…is a simple pattern that you can apply to a bounded context. It separates the domain model into two models: a read model and a write model (sometimes called a transactional model). 
The reason for the separation is to enable a model to serve the needs of a single context without compromise. The two contexts in question are reporting on the state of the domain and performing business tasks, also known as the read and write sides. Using a single model for bounded contexts that have complex presentation needs and rich domain logic often results in that model becoming overly complex and devoid of integrity, generating confusion for domain experts and a maintenance nightmare for developers. By applying the CQRS pattern, a model is split in two, enabling each model to be optimized to serve each context more effectively.
If you are anything at all like me, you’re probably eager to fire up your favorite IDE—doesn’t matter which though for me it would be IntelliJ IDEA—and bang out some code to put this CQRS thingamajig into action! YMMV, but when we all succeed, all of us here in programming digressions, we may well have on our hands something like this densely packed scenario such as the one in the picture below ⛹

I mean, where do I even begin with the richness of it all: The legion of IoT sensors in that demure house ceaselessly emitting signals, the embedded  micro-controllers attached to the handful of eucalyptus trees standing tall nearby (and ready to transmit perhaps their eucalyptus oil-levels in real-time), or perhaps that sharp S-shaped band in the adjacent road where we be driving our Ferraris (feeling safe in the knowledge that intelligent road-signs will communicate to approaching vehicles and alert them to programmatically reduce their speed)? ๐Ÿš• ๐Ÿš“ ๐Ÿš— ๐Ÿš™ ๐ŸšŒ ๐Ÿš› ๐Ÿšš ๐Ÿš“ ๐Ÿš’

(Akram, stop being lazy and just find and insert right here a link to the published conference paper or two that were based on your MS dissertation related to autonomously-intelligent vehicles using AI algorithms, including the trusty back-prop!) ๐Ÿ‘ฝ
19 b

19. Aspiring To Sublime Designs ๐ŸŒน

Hey, no Ferraris for us now; not right away, anyway. Meanwhile, let’s take in the penultimate picture or two below, that of the feathers of peacock. Are you, like me, also thinking to the timeless and inimitably graceful design that is the handiwork of Mother Nature? We—all of us technology types—can only aspire to design software that is a fraction as tasteful and graceful: Truly, the journey itself is the destination ๐Ÿšฅ ๐Ÿšฒ ๐Ÿšฆ
20 b

20. Raise Your Hand If You're Still Awake… ๐Ÿ˜ด

One If By Land, Two If By Sea.
~ Henry W. Longfellow (his eponymous poem, Paul Revere’s Ride)
Hang on, what kind of T-shirt is that, hanging on for dear life, clinging to a clothes hanger—which itself is hanging on for its life to a desultory doorknob in my sanguine study—with the lovely logo of the reactive summit which I attended in Austin not so long ago. But here’s the real deal: See that book, stoutly standing upright—Michael J. Casey's and Paul Vigna's fine book entitled The Truth Machine: The Blockchain and the Future of Everything—with my T-shirt in the background? And you may well be asking yourself, muttering under your breath no doubt, “Why has Akram wedged a Blockchain book in the guts of an essay that purportedly on DDD?" I wouldn’t blame you one bit if you did ๐Ÿ’ผ

Then again, I simply have to make sure—so I make unannounced checks  using the element of surprise—that my dear readers are still awake. And I kid you not: People have been known to fall asleep smack in the middle of reading my essays, and continue reading while sound asleep (that being the reading analog, of course, of sleepwalking!) ๐Ÿ˜ด

In the remote case that anyone is awake and—even more remotely still—they wish to look up my write-up on Blockchain, I can gleefully point you in the direction: Blockchain Adventures!
Truth machine b

21. It’s Now Or Never ๐ŸŽธ

After all has been said and done—here we tacitly acknowledge that a whole lot more has been said than done—we’ve reached the horizon of our journey: We are standing in front of a bridge in the countryside, a bridge that beckons us to venture outside our comfort zone. Tree-lined or not, easy or hard, straight or crooked, we simply have to cross that bridge.

Recall the image of the Tower of Babel which appears to atop this essay: Yes, far too much time has passed, far too many disconnects have taken place in the industry—technologists speaking one language and our counterparts the domain experts speaking another—that we can no longer afford to wring our hands in despair as we ruefully size up the situation in realizing that a lot of water has flowed under the bridge… ⛩

It's still not too late. But it is imperative that we cross the chasm. To put it in starker terms, it’s now or never.
17 b