Software Architecture: The Foundation of LearnFazz Mobile App

“Software architecture is a level of design that goes beyond the algorithms and data structures of the computation” — Garlan and Shaw

Software architecture designs and specifies the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives (Garlan and Shaw, 1994)

According to Kruchten (1999), Software architecture deals with the design and implementation of the high-level structure of software. While architecture deals with abstraction, decomposition, composition, style, and aesthetics.

Example of software architecture: layered architecture (Source: Richards, M., 2015)

As you can see from the picture above, the attributes of the architectural concept are:

1. Component → Encapsulated unit of software consisting of one or more modules that has a specific role and responsibility in the system
2. Connector → Architectural building block used to model interactions among components and rules that govern those interactions.
3. Architectural Configuration / Topology → connected graph of components and connectors which describes architectural structure.

To create an expendable and continuous software, it is crucial to have great software architecture. Why? Because, as time goes by, your software will be more and more complicated. Without any great foundation of software architecture and documentation, you will easily get confused about what should be in where, where this component should be, or what you did back then.

To prevent that thing from happening, especially because I am working with a team of 6 people, one of my teammates, Albertus created a software architecture that our team gets to use in this software development project, LearnFazz. LearnFazz’s software architecture consists of four main components (Mobile app/front-end, back-end, DBMS server, and an image server), three connectors (HTTP TCP/IP) and this such of topology that you can see in the picture below.

LearnFazz Software Architecture Diagram

Front-end (Flutter)

My team uses Flutter to make the front-end of our mobile app. Flutter is Google’s mobile UI framework for crafting high-quality native experiences on iOS and Android in record time ( https://flutter.dev/). Our team uses Flutter because of its fast development, expressive and flexible UI, and native performance that incorporate all critical platform differences.

On making the front-end using Flutter, our team uses the Business Logic Component (BLoC) pattern for the architecture. BLoC pattern is made to handle state changes in Flutter. It utilizes Reactive Programming (declarative programming paradigm concerned with data streams and the propagation of change) to handle the flow of the data. BLoC stands as a layer for our UI to interact with our back end. With this architecture, our team doesn’t need to store data in our UI (Widget, in this case). The architecture diagram of BLoC pattern can be seen on the image below.

Source: https://pub.dartlang.org/packages/bloc

On the deployment for front-end, our team does these following steps:

1. Get the Git commit ID from the latest commit in Gitlab
2. git tag (capture a point in history that is used for a marked version release (i.e. v1.0.1))
3. push it to deploy our team’s current front-end progress to HockeyApp.

For example, the commit ID is 1a85977396cae16d8c436a86140028edaa244673 :

git tag 0.2.95-staging 1a85977396cae16d8c436a86140028edaa244673
git push origin 0.0.1-staging

These lines of codes will trigger the Gitlab pipeline to execute. If the previous stages of development fail, the deployment will not execute. After successfully deploying to the development job, Gitlab will automatically build the app in HockeyApp that our team could download the APK(Android application package) from.

Back-end (Golang)

My team uses Golang to make the back-end part of the LearnFazz software. It is a statically typed, compiled programming language designed at Google. Our team chose to use Golang because of its speed and ability to work concurrently.

Our team uses the Domain-Driven Design (DDD) pattern for the architecture of back-end. DDD is an approach to software development based on a universal language between software developers and domain experts. The architecture diagram of DDD pattern can be seen on the image below.

Source: http://dddsample.sourceforge.net/architecture.html

According to the DDD website, DDD has 4 layers in the architecture:

• Interface: This layer responsible for the interaction with the user, whether software presents information or receives information from the user. This is the snippet of our course interface. You can see that the interface have functions that will respond if being called, in this example, respond if a course wanted to be built

• Application: This is a thin layer between interface and domain, it could call domain services to serve the application purposes. The code below will connect from the interface (course.go) to the domain.

• Domain: The heart of the software, this layer holds domain logic and business knowledge. This is the example of the course’s domain. It saves the location of each entity in the database.

• Infrastructure: A supporting layer for the other layers. This layer contains supporting libraries or external services like database or UI supporting library. Our infrastructure consists of cmd, configuration, database, firebase, migrations, and persistence. Here is the sample code of our database infrastructure.

Image Server (Firebase)

Firebase is a Backend-as-a-Service — BaaS — that grew up into a next-generation app-development platform on Google Cloud Platform. Currently, our team uses Firebase to store images. There is not much of the architecture of Image Server that I can talk about this.

DBMS Server (Postgres)

Database management system (DBMS) is system software for creating and managing databases (Margaret Rouse, 2019). DBMS provides users and programmers with a systematic way to create, retrieve, update and manage data. For this project, our team uses Postgres to make the database. PostgreSQL is a powerful, open source object-relational database system that uses and extends the SQL language combined with many features that safely store and scale the most complicated data workloads.

Our team relies on the provided Portainer by the Faculty of Computer Science Universitas Indonesia to deploy our back end server. Since our team’s back-end consists of more than one services (Server and DB), the deployment will be easier by using some kind of container (Docker) orchestration tool.

Docker Orchestration

To manage and maintain a large and dynamic environment, our team uses docker orchestration to manage the lifecycles of containers. For this project, our team uses Docker Swarm, a docker/container orchestration platform and is the native clustering engine for and by Docker. Any software, services, or tools that run with Docker containers run equally well in Swarm.

The reason behind the usage of Docker Swarm is because our team also uses Portainer. Portainer is a deployment tool that was provided by our faculty of this project.

Portainer Stack

To deploy something to Portainer, we will need some lines of codes to be run. This is a sample code of the file docker-compose.yml for deploying our team’s back end services:

version: '2'
services:
  postgres:
    image: postgres:latest
    environment:
      POSTGRES_DB: ${DB_NAME}
      POSTGRES_USER: ${DB_USER}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - learnfazz-staging-postgres_data:/var/lib/postgresql/data
    networks:
      private:
        ipv4_address: ${DB_PRIVATE_IP}
  backend:
    depends_on:
      - "postgres"
    image: registry.docker.ppl.cs.ui.ac.id/pplb4/back-end:${ENVIRONMENT}
    ports:
      - ${BACKEND_PUBLIC_PORT}:8080
    environment:
      DB_SOURCE: postgres://${DB_USER}:${DB_PASSWORD}@${DB_PRIVATE_IP}:5432/${DB_NAME}?sslmode=disable
    networks:
      private:
        ipv4_address: ${BACKEND_PRIVATE_IP}
volumes:
  learnfazz-staging-postgres_data:
    name: learnfazz-staging-postgres_data
    external: true
networks:
  private:
    external:
      name: learnfazz-${ENVIRONMENT}-private

This particular lines of codes contain 2 services: Postgres and back-end server. Both of them are connected to the same private network. The volume of docker-compose is mandatory for the Postgres database because of the reusability consideration.

References:

1. Shaw, M., & Garlan, D. (1996). Software architecture (Vol. 101). Englewood Cliffs: Prentice Hall.
2. Garlan, D., & Shaw, M. (1993). An introduction to software architecture. In Advances in software engineering and knowledge engineering (pp. 1–39).
3. Medvidovic, N., & Taylor, R. N. (2010, May). Software architecture: foundations, theory, and practice. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 2 (pp. 471–472). ACM.
4. Richards, M. (2015). Software architecture patterns. O’Reilly Media, Incorporated.
5. Martin, R. C. (2017). Clean architecture: a craftsman’s guide to software structure and design. Prentice Hall Press.