This post appears as an entry on my personal blog also: https://mydev-journey.blogspot.com/2019/11/business-logic-of-application-my.html

If you read my other blog posts, especially the first ones, I explain there that my background is 15 years of corporate controlling (management accounting). And 2019 was for me a transition year to - writing accounting/business software. I accumulated some SQL/C# skills in the last years, and using my business knowledge and logic, I try to build some real tools for my previous workplace's accounting department. I am a self-employed freelance contractor for them.

I can state at the beginning that having an accounting/controlling background is very useful to understand the logic of my apps. Their goal is to automatize the work of accountants, to reduce to minimum the need of using Excel files and many emails for data collection, approval etc. So, my business background proves to be helpful!

Afterwards, comes the design and programming part.

First I design the database, using an abstract model of the data that can be used in the app.

Understanding table structures and relationships in excel, and the workflow, I can build the SQL tables and relationships, keys, indexes, queries and reports that can be integrated to the application. I do this without having a formal training on how to build business applications, just following simple logic, then some database theory, SQL knowledge, normalization, etc.

Then I design the code and start writing it.

First, the models of the app will be representing these entities, shown above in the database section: SQL tables and relationships, and are the foundation of the application. Example: Business Units, Employees, Expenses etc. The models are written in POCO classes. I use Dapper, not EF for my projects. I don't use code first, rather database first, but my models are more or less equivalent to the datatables.

Then comes the application layer, with MVVM - a viewmodel that takes care of data coming from and going to the database, manipulating user inputs, checking, validating, iterating, etc... This I write in C#.

Then there is the View part of the application - written in WPF - for Windows, which is a quite simple interface containing user screens with tabs, tables (gridview), inputs, and reports plus some exports/imports/reporting of data. I try to make the user interface simple and easy to navigate, with a minimal risk to do stupid things. The users are happy, because they can use a centralized database app, and thus we can eliminate a lots of emails and excel files, which are very prone to mistakes.

As I progress with my application, I go back sometimes to redesign the database (add fields, indexes, tables), and also the code of MVVM above. This is an iterative process for me, like continuous improvement.

Last step is to populate the DB with data, and check. This is the most time consuming part, and can feedback to database design and coding.

What do you think? Would you do something differently? Is accounting background a disadvantage, or advantage? What should I focus on when writing such applications? Feel free to give me feedback on the above topics.