Clean Architecture: Xamarin.Forms

Intro

I have experimented with some architectural ideas for building applications and would like to share my thoughts.

Quote Builder

I wrote Quote Builder using Clean Architecture. I built the app with the lessons I learned from the last implementation in 2012. This app (Windows Store) has about 10,000 downloads.

Clean Architecture

I am a disciple of Martin’s teachings. As a result, I decided to implement my interpretation of his Clean Architecture idea. I built Quote Builder three years ago and tried my hardest to conform to Microsoft’s user experience guidelines for their Metro design. That resulted in a third of the app’s ratings being one-star.

The client architecture of that version is below:

MetroArchitecture

The Clean Architecture approach that I built with Xamarin.Forms is the following:

XamarinArchitecture

A user-story module within the architecture is as follows:

XamarinSolutionExplorer

The Solution Explorer for the Windows Store app looks like the following:

MetroArchitecture_solutionExplorer

The Solution Explorer for Xamarin.Forms app looks like the following:

Xamarin_solutiion_explorer_architecture

The following table reflects code analysis results of the application including user story modules:

CodeMetrics

Retrospective on Clean Architecture

When I rewrote Quote Builder for Xamarin.Forms, I created a project per user story. I also created a unit test project per user story. This resulted in about 45 projects within my solution. Thus, this gave me long load times (approximately 15 seconds) when opening the solution in Visual Studio 2015. I also found myself waiting for half a minute each time I would build my solution. As a result, I consolidated my unit test projects to just one project which reduced load-time by a third.

Teams implementing Clean Architecture, need to respond to the organic growth of the software over time in which the application becomes proliferated with projects that take will eventually take a toll on a solution’s load-time and build processes. There are workarounds though. For example, multiple projects can be consolidated to one project based on the related concerns of user story modules. In addition, other solutions can be created per related set of modules. This will enable a solution to replace project dependencies with DLLs. Performing this substitution will reduce the time to load a solution, build it, and execute unit tests by orders of magnitude faster than relying on only projects.

I also like the side-effect of isolating user story modules. Hence, this architecture reduces the likelihood for the codebase to experience entropy. For example, the isolation of each user story module enables code analysis to be utilized more effectively. Hence we can now scrutinize each user story’s implementation which (because of this architecture) is now in complete isolation of other user stories. For example, we can now examine the maintainability index and code coverage from unit tests targeting a specific user story module. Thus, isolating user stories into independent modules for developers to pull from, will encourage developers to finally acknowledge ownership of their code’s quality because no other developer will modify their module without the owner’s review and approval. Another benefit is that user story modules that were poorly implemented can now be refactored or in some cases rewritten without having to rewrite a significant portion of the application. Also, developers that do hold themselves accountable for the quality of their code are  now enabled to lead by example. Hence, because their user story is isolated from the modules that other developers are tasked with, quality focused developers can now own the quality of their story and demonstrate how to write solid code with outstanding code coverage which other developers can reference and learn from.

I am not convinced that implementing Clean Architecture is worth the overhead for a single developer project. I do believe that this practice will encourage developers to be more surgical when it comes to maintaining an application’s architecture due to isolated user story responsibilities.

In addition, I do believe that clean architecture makes software more maintainable over the long run. Developers can now zero-in on a user story module that’s most likely to host a reported bug. It also compliments Visual Studio’s CodeMap so that maintainers can identify dependencies of specific user-stories as the user-story module diagram conveyed.

Conclusion

In conclusion, I ported a Windows Store app to Xamarin.Forms using Clean Architecture. I provided disclaimers about using Clean Architecture in regards to load-times with Visual Studio solutions and what can be done to resolve those concerns. I also identified the benefits of leveraging this pattern in regards to refactoring or rewriting a user story module as well as the increase in code quality.

NOTE:

Scott Nimrod is fascinated with Software Craftsmanship.

He loves responding to feedback and encourages people to share his articles.

He can be reached at scott.nimrod @ bizmonger.net

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: