/
Overview of Code Structure

Overview of Code Structure

The aim of this document is to explain the code structure of the Score project and thus make it easier for new developers to start contributing to the project.

Score Architecture

The overview of Score architecture is presented in the image above. Score project consists of 4 services:

  • score-web: front-end service which is written in Angular framework.

  • score-http: back-end service which is written in Spring Boot framework.

  • score-repo: MySQL database for persistent data.

  • session/cache: Redis data storage for cache purposes.

This document will discuss in detail the first two services, front-end written in Angular, and back-end written in Spring Boot, since they are the services where a new developer can contribute the most.

score-web: Front-end service

The front-end of the Score project is written in Angular. Developers who want to contribute should be familiar with the Angular framework and development process. The project is organized into modules. Each front-end unit for representing UI components in HTML pages has its own module.

. ├── app │   ├── account-management │   ├── agency-id-list-management │   ├── authentication │   ├── basis │   ├── bie-management │   ├── cc-management │   ├── code-list-management │   ├── common │   ├── context-management │   ├── log-management │   ├── message-management │   ├── module-management │   ├── namespace-management │   └── release-management ├── assets │   ├── css │   ├── fonts │   └── i18n └── environments

In terms of code structure, each module is organized in the same way. The module contains components, which are equivalent to web pages. Every component (i.e., web page) has its package (folder), which always has the following files:

  • <module>.component.css: All styling code goes here.

  • <module>.component.html: Defines the structure of the web page.

  • <module>.component.spec.ts: Specification of the component is stored here.

  • <module>.component.ts: The main business logic that provides data and makes actions possible is stored here.

Besides component folders, every module has a domain package. Domain holds the code that communicates with backend service and provides data. It has one or more service files. Services files hold the functions that manipulate data objects (select, create, insert, update, delete). Besides service files, there are class files where classes for manipulating data objects are defined (with getters and setters).

. └── app    └── account-management ├── account-create    │ ├── account-create.component.css    │ ├── account-create.component.html    │ ├── account-create.component.spec.ts    │ └── account-create.component.ts ├── domain │ ├── account-list.service.ts │ └── accounts.ts ├── account-management.module.spec.ts └── account-management.module.ts

In the end, the module has two more files:

  • <module>.module.spec.ts: Specification of the module

  • <module>.module.ts: Definitions for all components and routes are stored here.

score-http: Back-end service

The back-end project is written in Spring Boot and consists of several backend modules. These backend modules are:

  • score-http: contains all controllers and request mapping services defined by Spring MVC structure.

  • score-repo: contains implementations using jOOQ for the data access layer.

  • score-repo-api: represents an abstract interface of the data access layer.

  • score-service: contains all business logics communicating with database.

Please note that backend modules are parts of the code structure, i.e., sub-projects of the Score backend project, and they are not equal to application modules (i.e., web pages) mentioned above.

. ├── score-http │   └── src │      ├── main │      └── test ├── score-repo │   └── src │      ├── main │      └── test ├── score-repo-api │   └── src │      └── main └── score-service └── src    ├── main    └── test

Dependency management is achieved using Maven and all dependencies are defined in the pom.xml file. Please note that there are general and module-specific pom.xml files.

score-http module

The score-http module can be considered as the main module and entry-point to the backend of the Score project. It’s organized into the packages following a common backend organization approach:

  • gateway.http - Entry point to the project. Contains the definition of all controllers.

  • repository - Holds simple get repositories for every database table (Note: this package should be removed and will move to score-repo-api/score-repo modules.)

  • data - Consists of data transfer objects (DTOs) used for holding query results in a serializable friendly manner (Note: this package should be removed and will move to score-repo-api/score-repo modules.)

  • repo - Data Access Layer that holds objects and repositories that makes communication with the database easier (Note: this package should be removed and will move to score-repo-api/score-repo modules.)

  • cache - Package that holds caching logic.

  • redis - Package that holds Redis configuration.

  • common - Package that holds constant properties, enums, and utility functions.

  • export - Package that holds business logic for retrieving and unification of Score data for export.

  • populate.helper - Help functions for populating Score data from XSD files (This was used when OAGIS 10.6 was first imported into Score database. Currently, it is not used in the project).

The request processing workflow follows the workflow in the Spring Web MVC framework. Generally, ‘controller’ package contains all request handlers based on the @Controller annotation. The controller delivers the request to business logic handlers described in the ‘service’ package with the @Service annotation-based classes, and transfers business data to the database through queries defined in the ‘repository’ package.

Moving forward, the gateway.http package defines entry points to the project in forms of APIs (application programming interfaces). APIs are defined into module-based packages. Each module-based package contains:

  • controller: holds controller definitions

  • data: holds classes that defines request and responses object structure

  • repository: in charge of communicating with database (Note: this package should be removed and will move to score-repo-api/score-repo modules.)

  • service: holds business logic (Note: this package should be removed and will move to score-service modules.)

Besides api packages, gateway.http contains configuration package with the following code structure:

  • handler: defines exception handlers

  • initializer: holds database connection initialization

  • oauth2: contains oauth2 security logic

  • security: contains security logic about user and session management

  • websocket: contains definitions of entry points for web socket communication

  • event: definitions of the messages used to trigger specific events

  • helper: utility functions for GUID, string, zip, query manipulations

score-repo-api module

This module contains interfaces and POJO classes that defines repository API. The content of this module is self-explanatory. In the future, we will move some components in ‘repo’ and ‘repository’ packages in the score-http module into this module.

score-repo module

This module contains CRUD repositories for each project module implemented using jOOQ database-mapping library. The content of this module is self-explanatory. In the future, we will move some components in ‘repo’ and ‘repository’ packages in the score-http module into this module.

score-service module

This module contains business logic used for the defined Score processes. The content of this module is self-explanatory. In the future, we will move all components in ‘service’ packages in the score-http module into this module.

Related content

Overview of Score Database Structure
Overview of Score Database Structure
More like this
Overview of Test Case Document
Overview of Test Case Document
Read with this
Multi-tenant
More like this
Multi-tenant (before requirements simplification)
Multi-tenant (before requirements simplification)
More like this
'Choice' and 'Attribute Group' types in ACC
'Choice' and 'Attribute Group' types in ACC
Read with this