Story Driven Architecture

Intro

I find myself a disciple of Robert Martin’s teachings. Specifically, I am in love with his recommendations of architectural design. He has given several talks on Clean Architecture. He also has an article of it here

“Software doesn’t need architects to design it. It needs architects to review it.”

What I am not a disciple of are people who continuously try to pretend that they know exactly how a system is going to work based on limited requirements handed down from the client. These people love to draw on whiteboards and software applications that provide UML editors. These people continue to believe that they know everything about a system and will attempt to convince you to implement their psychic readings. They believe that if an object exists in the business world than an entity is required to represent it in software. Unfortunately, failed projects have proven that as much as we try to anticipate how a system is going to work, we will always make discoveries and have to adapt to them when we actually attempt to implement the visions handed down from these divine architects.

“Software is “soft” because we have the freedom to defer decisions all the way to the end.”

Software is not about architectural design. It is about isolating thoroughly tested logic that’s generated from unit tests, that when refactored into logical components, will expose an architecture that conveys the user-stories that created it. Thus, an authentic software architect recognizes software as being “soft” only when they pragmatically defer architectural decisions for a later time up-until they have reached a point of an authenticated impediment. It is at that time within the SDLC that a developer / architect can make a more informative decision based on additional information that has become available that just wasn’t prior. Thus, it is really deferring decisions all the way to the end that results in software being “soft” and the combination of isolated stories with associated unit tests that removes unnecessary dependencies and enhances flexibility.

Composing an architecture as a collection of user-stories

      • Each user-story is a self-contained module and can only subscribe to messages or publish messages without having any knowledge of the outside world (i.e. client/server).
      • Each user story is tested in complete isolation of other user-stories and again are agnostic to any client or server dependencies via a message-oriented architecture.
      • Start off creating a library / module for each user story
      • This methodology supports Single Responsibility Principle (SRP)
      • Definition of SRP: Keep code together that tends to change together and pull code apart that tends to change for different reasons.
      • As user-stories get implemented, each library representing a user story is evaluated with other user-stories to determine if any of these libraries can be consolidated into a single library that maintains compliance with SRP.

Testing user-stories

      • Unit test only view-model commands and nothing more.
      • Inject test dependencies that will dictate test behavior as a light-weight integration test or unit test.
      • RGR (Red, Green, and Refactor) test code into logical components that will eventually distill into a story driven architecture.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: