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 physic 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 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 was 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 ssociated unit tests that removes unnecessary dependencies and enhances flexibility.

Story Driven Architecture

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

Thanks!