So far in this series, I’ve been talking about concepts related to re-building my mobile app - the why, what and how - and haven’t shown how I’d start implementing it. This post is about just that - the project/solution structure and how I’ve set it up in Visual Studio so I can build the rest of the app.
This post is part of a series on my journey rebuilding my app and learning a lot of new stuff. Other posts in the series:
Series: All About Money - A journey to build a mobile app
- The state of the app
- The goal: first x-platform release
- Thinking functional and DDD - in the personal finance tracking context
- The new Project structure
- Design of the existing app
- UI and wireframes
… more to come …
- The final push to release
Given I plan to target Windows, and Android for this next release, and I’m using Xamarin and MVVMCross, I’ve factored out the common code into PCLs (portable class libraries). As of now, my project structure looks like this:
I’ve created the
Money.Droid.UI projects - that represent the UI for the respective platforms (and includes the views for tablets and phones) - in C#, because I had a bunch of problems using the latest version of F# (v4.0 at the time of writing) with the latest version of Visual Studio (2015) and Xamarin (v 3.11.837). The tooling with Xamarin just didn’t support the latest F# targets in VS 2015, and VS doesn’t natively include F# project templates for creating WinRT XAML projects. (I’d imagine I could hack together something to make it work - but I’d lose a lot of tooling support - and for the UI aspects, I decided to continue using C# and get the support from better tools).
Money.Domain project contains the domain model - for the command-side of CQRS and the intent is to have the command handlers and the domain events in this project.
Money.Data project is where I plan to add the event handlers which store the data as a stream of events to a simple JSON file store (looking at NEventStore for this - but it lacks PCL support; I might have to add it in if possible without distracting me too much from this project);.
I have a data generation aspect - where I generate fake/demo data (possible some TransactionCreated events) - which will serve as the initial starting point for users trying out the app in the ‘demo’ mode where it already shows various screens filled in with some canned data. The code for this will probably live in the Money.Data project.
Money.Queries project is for the read-side of CQRS. I’m not sure if it is worth separating the read and write sides - but it helps me avoid accidentally falling back to regular N-tier style design where reading/writing often tends to share the same classes to interact with the data store.
With this project structure, the current dependency graph looks as follows:
The UI projects will be the entry points into the app. The platform specific UI will call into services / view models from the common UI - which will then issue appropriate commands and queries that either directly interact with the data store or process the commands via the domain model to generate events which will be handled by classes in the data store to persist the event stream.
With this structure in place, I can now proceed to build out the rest of the application. I do want to reuse a lot of the UI elements and UI-related infrastructure code from the previous version of the solution (the Windows 8 app). Also, a lot of the read-side code will probably be just a straight port from C# to F# - given the C# code in that area is already portable (as in PCL) and written in a functional-style.
In the next post, I’ll describe the project structure of the existing solution to put future posts in context - whenever I refer to code-snippets / classes from the existing solution.
Soon, I also plan to push the code to github, so those following the series can look at the code as well.
Eventually, I intend to do a comparison of the new language + architecture with the existing solution.