Repositories and Data Access Objects are still alive

In my previous articles when I was talking about Clean architecture and Domain Driven Design I mentioned one piece of domain layer – repository or more precisely repository pattern. The repository pattern is used to persist and retrieve domain models. Although repositories are mostly related to Domain Driven Design the other architectures might have the objects with the same functionality but are called different. In Fitradar application (front end and back end) the objects that are used to persist data in the database and fetch data from the database and map data to in-memory objects (aka POCO – Plain Old C# Object, POJO – Plain Old Java Object) and are not part of the Domain layer are called DAO (Data Access Objects). DAO usually are used in cases when no business logic is involved and the application needs to execute simple CRUD operation.

In Android application to work with database we use Room Persistence library but in our back-end solution we use Entity Framework Core. These two are know as Object-relational mappers or ORM. And today I wanted to explore the relationship between Domain Repositories, Data Access Objects and ORM and share some experience we had in our team working with these patterns and libraries.

If you look at the responsibilities of Repository, DAO and ORM they are very close to each other. Some years ago when ORM technology was in its inception the DAO and Repositories usually were working directly with the low level database access services. In case of .NET it was ADO.NET library and in case of Android it was SQLite library. And it was quite clear that DAO or Repository should use these libraries to persist or retrieve in-memory objects and map the data. But now-days when in application development main data access technology became ORM the border between ORM and DAO and Repository has become very blur, especially when one just switched to ORM. Working with ORM in different projects and languages our team came to conclusion that in same cases ORM can fully replace the DAO or Repository and can be used instead of it. Let’s look closer at the cases when it is appropriate to use just a ORM library and when the DAO or Repository should be used in combination with ORM:

  • If you need to save, update or delete single flat plain old object then in most cases ORM library will do the job for you. Of course EF Core and Room are capable of doing more, but then we really should investigate each case separately
  • If you need to fetch the data from single table by primary key then again in most cases you can fully relay on ORM
  • In case Domain layer aggregate has complex entity cluster hierarchy, where different entities might have different persistence state you most likely will need to write such aggregate persistence logic by yourself either using ORM or low level database access library. In our application one such aggregate is Sport Event that has Place and Organizer and some other entities. And the problem we faced when tried to save Sport Event by using built in EF Core capabilities was the different Entity State and the calculated state before Save operation. For example we had cases when we needed to create a Sport Event in Place that was not yet saved in database, and since both entities have the same Entity State EF Core tackled that case well and was able to create both entity records in database. But the problem started to appear when we wanted to create Sport Event in the Place that already had other Sport Events, now before saving aggregate Sport Event we had to fetch Place entity to make sure EF Core sets the correct Entity State. And the more entities your aggregate root has the more fetch operations might be needed. So in this case for us seemed obvious putting Entity State synchronization logic in separate Repository.
  • In case data query logic and following mapping logic is so complex that to make a code readable it is necessary to split logic in separate functions, you most likely will move those functions to separate class, Data Access Object, to persist the Single Responsibility principle.

As you can see the Repository and DAO still has their place in the modern software architecture. In case of queries in CQSR architecture query logic might be put in Application layer since anyway contrary to Commands, Queries only responsibility is data fetching, and that duplicates DAO responsibility. By choosing to put query logic in Application layer we make a direct dependency on EF Core. That is not a problem in classical three layer application, but it does not fit the Clean Architecture principle where Application layer should be aware only of Domain layer and with outer layers (EF Core belongs to the Infrastructure layer) communicates only through interfaces. In this case we should use DAO.

Please visit our website and join the mailing list. Our app is coming soon:

http://fitradar.me/

Clean architecture for our back-end

Today I want to continue discussing the architecture we came up with for our back-end service. In the previous article I brought up some arguments why it was important for us to separate read and write models. And the main thing that made it clear was that we operated with two different data sets for read and write operations. But I didn’t go much in to the details on how we arrived at such a different models. And this aspect of CQRS will be the topic of today’s article. Before we even realized we need to apply CQRS pattern in our design we decided to follow Uncle Bob’s Clean Architecture the same architecture we used in our mobile application development.

And the the reasoning that brought us to this architecture I lied down in one of my previous articles. Although on both platforms the overall architecture was the same but implementation details were quite different. The main attraction point of this architecture was possibility to build the server side application around the Domain Model and apply Domain Driven Development. There are several definitions for Domain Model and some of them you can find here but for us in the design process more important was to understand the peaces that constitute the Domain model. It allowed us in the next designing steps to decide whether we need a separate Domain model layer or entities were just enough. Quite often I notice that the architecture does not make a big difference between the bare bones domain entities and full domain model. In first case entities are just a database relational model, and they serve as in memory tables. In many cases especially in ASP.NET world (the framework we are using to build our back-end services) Object Relational Mappers like Entity Framework require to separate entities from the CRUD operations and thus giving impression that full-fledged Domain model is created, but in fact you end up with something what is called Anemic Domain model which is considered an anti-pattern. So following the advise of Eric J. Evans in his book Domain-Driven Design: Tackling Complexity in the Hart of Software we noted for ourselves following parts that should be presented in our Domain Model in order to consider it us a separate layer:

  • Entities accompanied with business methods
  • Value objects
  • Repositories
  • Aggregates
  • Bounded Context

By analyzing our model designed for Android or iOS platform and for our back-end platform we realized that only our back-end model meets Domain Model criteria and deserves a separate layer but in case of mobile phone platforms we ended up with simple entities that were the part of application or Use Cases layer.

By modeling entities we replicate real life entity attributes, like person’s name, surname or gender that are operated by methods encapsulated in the same entity or in service. At the end of the modeling process we come up with our business model that further can be converted to the Entity-Relationship model, that is used to build the database. In such way Domain model or plain entities are tightly bound to normalized ER model. And one can live only with one ER model until the moment when displayed information starts more and more deviate from the ER model and in order to fetch the data from database more complex queries are required. And this is the time when we started to consider CQRS. But now it was not clear how to integrate the CQRS in Clean Architecture layers and we turn to the mighty Google for someone’s else experience and we found this wonderful talk that showed us exactly what we were looking for and so we ended up by extending the application layer with commands and queries and adding separate Database context or our queries.

Please visit our website and join the mailing list. Our app is coming soon:

http://fitradar.me/

Study: fitness boosts brainpower in adults

Physical fitness has been associated with better brain structure and brain functioning in adults.

The findings of a study, led by Dr Jonathan Repple of the University Hospital Muenster in Germany, suggests that increasing fitness levels through exercise could result in improved cognitive ability – such as memory and problem solving – as well as improved structural changes in the brain.

A group of researchers led by Repple used a publicly available database of 1,200 MRI brain scans from the Human Connectome Project and combined it with physical testing to assess the subjects’ physical fitness. Each one’s cognitive ability was also measured. The researchers excluded subjects with pre-existing conditions, such as neurodevelopmental disorders, diabetes or high blood pressure.

The results of the study showed that physical endurance was positively associated with the global cognition scores of the subjects taking part.

In its conclusion, the group of researchers said the results of the study suggest that physical exercise could be used as a form of preventative healthcare.

“The observed pattern of results appears to support the notion of a beneficial effect of physical fitness on cognitive function,” the study reads.

“This notion is supported by the few available experimental studies indicating that physical exercise leads to increases in memory performance and brain structural integrity.

“This concept might be of relevance for a wide range of domains in health and life sciences including prevention, clinical care and neurobiological research.

“Along with previous findings, our findings point to the potential of physical fitness as a modifiable factor that might be applied as an intervention in prevention and clinical care.”

The report was simultaneously published in the Scientific Reports journal and presented at the ECNP Congress in Copenhagen, Denmark.

To read the study in full, click here.

Source: http://bit.ly/30Pqjy3

Please visit our website and join the mailing list. Our app is coming soon:

http://fitradar.me/

Keeping Write and Read operations separately

In this article I wanted to share our team experience on how we arrived at particular architecture on our back-end solution. On the back-end we wanted to work with technologies that our team is familiar with and had an experience with before but at the same time is not outdated and has a great potential in the near future. In our case it was ASP.NET Core framework. I am not going in to the endless discussion about what framework or language is the best, from my point of view it is useless since such a topic is very biased. And I already mentioned in one of my previous blogs that despite the fact that the software development supposed to be an exact science, and many aspects of it really is, the choice of language, frameworks and best practices many times is just a matter of personal preference – something that you feel more comfortable with and it doesn’t have any scientific justification. And when I will be laying down the arguments for the solution we came up with it will be presented from our team’s point of view and how it helped us to make a design and implementation more clear and easier to understand, which might not be the case for other teams.

ASP.NET Core comes comes with some prepacked architecture that satisfied our needs. For REST full Web API solution MVC is very suitable design pattern and gave us a good starting point. Dependency injection in turn allowed us easy start to write unit tests and mock dependencies. But the more complex solution became the more we saw that we need to extend our initial project with more general architecture, after all MVC is just an UI level design pattern. This wasn’t the first project in our team’s experience when we had to split application’s code in layers. Some years ago very common was 3 tier architecture:

Three tier Application

And we used this architecture quite a lot. In some projects we felt it suited our needs perfectly, but in some we had a feeling that we do some kind of workaround to fit the architecture. For some time I could not really even explain why those projects didn’t comply with the above architecture until the moment when I read about Command and Query Responsibility Segregation (CQRS) pattern. It was one of those aha moments when you discover what was really bothering you all this time. In the traditional 3 tier architecture the same data model and the same database is used for read and write operations. It works well when we need to display the same information we saved earlier. But the more complex application becomes the more a model we use to save data starts to deviate from a model we use to display data. For example most of the applications today require a user to create a profile or an account. Let’s say we save this information in table User and in order to do that we use an model with the same name. In case we want to see our account information we will fetch the data from the same table User. But this is only one use case where we are displaying the information about user. In real world applications information about user is displayed in many other pages together with other information, for example in e-store that would be information about product and product category, in blog that would be a post and so on. And in order to receive data suitable for a view complex queries with joins and sub-queries are used. And not only models for read and write operations are different but the requirements for those operations are different as well. In case of insert update and delete operations the database should be normalized that allows us to minimize duplicate data and avoid data modification issues. The database normalization usually results in more tables than initial design. The query operations on the other hand are focused more on performance, that can be improved by denormalizing tables. The beauty of CQRS is that it allows to separate the write and read flows by using different models and even different databases. In last case it would allow to scale the databases for read and write operations independently. And at some point of time this feature may become very crucial since write operations are significantly less that queries. As you can see there are several levels how far we can separate commands (insert, update, delete operations) from queries (read operations):

  • The lowest level of read and write operation separation is on Repository level – we are using the same Domain model for write operations and for display data in UI, but we have a separate method in Repository for querying database. In order to display only necessary data we have to introduce View model and map data from Domain model to View model.
  • Next level of CQRS maps View Models directly to database queries. There is no need for mapping between Domain model and View model anymore. On database level we still have normalized tables that correspond to Domain model. View models in this case correspond to queries that involves joins and sub queries.
  • The two above levels of separation sometimes are not regarded as real CQRS pattern but are known as CQS (Command Query Separation) pattern, therefore only the next level of separation when write and read operations are regarded as two separate workflows throughout an application is considered as CQRS pattern.
  • The final level of separation goes further even to the database layer, where each type of operations interact with its own database

In our back end API solution we decided to separate write and read operation on the application level and not to use a separate storage, but instead we are using SQL Views for queries. It allows us avoid data synchronization between the databases. But at the same time architecture is opened for further extension and possibility to add separate storage for queries. And so we ended up with following architecture:

Visit our website and join the mailing list. Our app is coming soon:

http://fitradar.me/

Bringing security in FitRadar solution

In this article it is time to talk about how we secure our mobile application and our back-end API. Most of the information displayed in Fitradar mobile application is user dependent. Starting with user profile that has unique information for each user and can be changed or deleted only by the owner of the profile and ending with sport events map and timeline where information is built based on user preferences. And we have to provide access to third party integration services like Firebase Storage and payment gateway. As you can imagine in order to allow our application users to store and access personal information in a secure way we needed to implement user authentication and authorization.

It was clear from the very beginning that we are not going to develop our own authentication service but instead we will use third party solution. And before we started to explore available solutions we laid down following requirements:

  • the access to Fitradar Web API should be granted only to authenticated users
  • the access to Fitradar mobile application should be granted only to authenticated users
  • the access to Fitradar Web API should have different privilege levels
  • the access to third party resources like Firebase storage should be granted from the same authorization service
  • the sign up and sign in pages should be part of the Fitradar app

After some investigation we came to conclusion that combination of OAuth2 and OpenID Connect protocols is the best solution for our needs since it:

  • provide a mechanism for our resource and third party resource protection
  • authenticate users using local or remote account store

Once we were clear about the authentication flow and protocols we started to look for the OAuth2 and OpenID Connect protocol implementation providers. First we wanted to have as much as possible control over authorization service, because we didn’t want to land in situation where authorization service would restrict our application look and functionality. For example RFC8252 (OAuth 2.0 for Native Apps) states that: “OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user’s browser.” And that might enforce our app to use authorization server sign in and sign up user interface. And since on our back-end we are using ASP.NET Core we decided to use IdentityServer. For a while it worked quite well, but then we started to noticed that there are few aspects of the OAuth2 protocol that we have to implement by ourselves, like Access token lifetime in our mobile app. So we started to feel that we are spending too much time on implementing and maintaining the protocol features that we were quite sure should be working out of the box. Although IdentityServer offers full fledge OAuth 2.0 and OpenID Connect implementation but we still had to host it on our environment and maintain it by ourselves. And the maintenance question bothered us the most. For the startup company with limited human resources to have a solution that might require an administration seemed for us a high risk. If something goes wrong with authentication we will have to put all our effort to fix it, which means the other work will suffer from it. So we decided to look for a cloud solution that would free us from the maintenance burden. And once again we searched for available authentication and authorization providers but this time on a cloud. And after a while we came up with two potential providers: Firebase Authentication and Azure Active Directory. First Active Directory seemed a good solution for our needs:

  • very well established user management system (although we just needed a tiny portion of all available feature)
  • good documentation and code samples
  • very easy integration with .Net Core
  • possibility to use custom sign up and sign in pages

Although Azure AD integrated very well with our Web API and there are good sample projects how to use it with Android and iOS applications we were not sure how well it will integrate with Firabase Storage that we are using to store user images. It turns out we can grant the access to the Firebase storage resources only to Firabase users. To integrate with other OAuth providers Firabase creates a new user account after user has signed in for the first time and links it to the credentials. The fact that we would have user accounts on two authorization servers that we have control over really held us back from integrating Azure Active Directory B2C in our solution. From the other hand we were hesitant to start to use Firebase Authentication service in our ASP.NET Core solution as well, since we were not sure how much time and effort it will require from our team. But after all the Firebase Authentication is just another OAuth 2.0 and OpenID Connect provider that issues identity and access tokens and Jwt bearer authentication middleware in ASP.NET Core application can validate those tokens and authenticate a request. So we decided to spend some time to create a proof of concept project that would show us how much time we will have to invest in order to integrate Firebase Authentication in our Web API authentication solution. And it turns out that requires just a few lines of code in Startup.cs file:

services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options => {
        options.Authority = "https://securetoken.google.com/fitradar-firebase-project";
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "https://securetoken.google.com/fitradar-firebase-project",
            ValidateAudience = true,
            ValidAudience = "fitradar-firebase-project",
            ValidateLifetime = true
        };
});

And bellow is the final solution we are using to secure our and third party resources and authenticate a user

Please visit our website and join the mailing list. Our app is coming soon:

http://fitradar.me/

50 Great Reasons To Exercise

  1. Lifts your mood
  2. Improves learning abilities
  3. Builds self-esteem
  4. Keeps your brain fit
  5. Keeps your body fit & able
  6. Boosts mental health
  7. Boosts your immune system
  8. Reduces stress
  9. Makes you feel happier
  10. Has anti-aging effects
  11. Improves skin tone and colour
  12. Improves sleeping patterns
  13. Helps prevent strokes
  14. Improves join function
  15. Improves muscle strength
  16. Alleviates anxiety
  17. Sharpens memory
  18. Helps to control addictions
  19. Boosts productivity
  20. Boosts creative thinking
  21. Improves body image
  22. Gives you confidence
  23. Helps you keep focused in life
  24. Improves eating habits
  25. Increases longevity
  26. Strengthens your bones
  27. Strengthens your heart
  28. Improves posture
  29. Prevents colds
  30. Improves appetite
  31. Improves cholesterol levels
  32. Lowers risk of (certain) cancers
  33. Lowers high blood pressure
  34. Lowers risk of diabetes
  35. Fights dementia
  36. Eases back pain
  37. Decreases osteoporosis risk
  38. Reduces feelings of depression
  39. Prevents muscle loss
  40. Increases energy and endurance
  41. Increases sports performance
  42. Increases pain resistance
  43. Improves balance and coordination
  44. Improves oxygen supply to cells
  45. Improves concentration
  46. Helps with self-control
  47. Lessens fatigue
  48. Increases sex drive & satisfaction
  49. Makes life more exciting
  50. Improves Quality of Life

Visit our website and join the waiting list. Our app is coming soon:

http://fitradar.me/