Tag Archives: agile


I decided to work on my Portfolio targeting the mobile space. In doing so, I plan on leveraging F# and Xamarin.Forms.


I’m an advocate of Clean Architecture. As a result, I like to take time to configure my solution explorer. When I’m configuring my solution explorer, I want it to reflect application’s intent.

My solution explorer is below:


In the solution explorer above, I have partitioned my application into three segments:

  • Domain – This conveys the intent (i.e. features) of the application.
  • Integration – This manages IO interactions such as UI and web services.
  • Tests – This manages the feedback loop of correctness as I crank-out business logic.


The following image reflects the Domain segment of my solution explorer:


The image above reflects the projects that map to application features. Having a set of related features mapped to a project library could be beneficial when leveraging static analysis tools. Hence, related features can be isolated and scrutinized for maintainability metrics and code coverage. The information acquired from these static analysis tools can then be fed to QA so that they can make better informed decisions regarding their test strategies and exploratory testing.


The following image reflects the Integration segment of my solution explorer:


The image above conveys the integration points that my domain relies on. In this case, my domain relies on UI (i.e. Xamarin.Forms) and services (i.e. web services). Note, how I did not configure my application within Solution Explorer to be Xamarin.Forms centric. Hence, I prefer that my domain be loosely coupled if not decoupled from any framework.


The following image reflects the Tests segment of my solution:

The Tests segment of the solution explorer contains a TestAPI that not only feeds my unit tests input for execution, but also can also be used to feed the actual application itself. This is very useful when identifying anomalies within the application as business logic errors or integration errors. Thus, using this process of elimination will contribute towards a faster resolution as well as cost savings.


I continue to build systems inside-out. Specifically, I focus on implementing the policy (aka: business rules) first. I then throw up just enough UI to flush-out edge-cases that my implementation did not yet handle. That activity is still focused on solidifying the policy so that I can expose as many anomalies as I can early within the SDLC (Software Development Life Cycle). I eventually implement the integration details such as a polished UI, web services, a database, etc.


In conclusion, I discussed my plans to build a trading application so that I can add it to my portfolio. I then discussed how I configure my solution explorer in an effort to provide separation of concerns for my overall solution.


I’m chopping it up with Ody about F#, Property-based Testing, Akka, etc.

Reactive Programming – 2:52
Akka dot Net – 23:26
Immutable Databases – 37:00
Architects + F# – 47:00
Multi-Threading Discussion – 52:22
Testing Discussion – 58:45
Codebases and Architecture – 1:17:23
Property based Testing – 1:32:33
F# vs C# for User Interfaces – 1:44:00
Motivation for Software Developers – 1:57:20
Is there any need for a Database? – 2:03:00
Architecture – 2:12:00