Skip to content

THETOUCH/stage3-module2-task

 
 

Repository files navigation

Spring Core

Task

Recommended Timeline

The recommended timeline for the whole module is 2 weeks.

Business requirements

  • Migrate your solution prepared in Architecture advanced module to Spring.
  • Support CRUD operations for Author as well.

Prerequisites

You are provided with the basic interfaces for repository, service and controller layers:

  • com.mjc.school.repository.model.BaseEntity
  • com.mjc.school.repository.BaseRepository
  • com.mjc.school.service.BaseService
  • com.mjc.school.controller.BaseController

Use them as base point for your solution. Do not change or delete them.

DataSource

Domain objects are represented by the following diagram

and have the following requirements:

  • All fields for News (except authorId) and Author are required.
  • Id fields should be auto generated.
  • News title field should have length from 5 to 30.
  • News content field should have length from 5 to 255.
  • News and Author createdDate, lastUpdatedDate fields should be in ISO 8601 format. Example: 2018-08-29T06:12:15.156. More discussion here: stackoverflow: how to get iso 8601 .
  • News authorId field should be mapped to the author datasource.
  • Author name field should have length from 3 to 15.

As well as in the Architecture advanced module data source should be generated automatically at runtime and saved in array datasource by reading files from the resources folder in the repository module (database emulation).

For example: author.txt, content.txt which should contain the required data.

Operations

The system should expose CRUD operations for News and Author from the main module in the root project:

  • Create News - fill only title, content, authorId and return created news.

  • Create Author - fill only name and return created author.

  • Get All News – return list of news.

  • Get All Authors – return list of authors.

  • Get News by id – return news by provided id.

  • Get Author by id – return author by provided id.

  • Update News – update only title, content, authorId by provided news id and return updated news.

  • Update Author – update only name by provided author id and return updated author.

  • Delete News – delete news by provided news id and return boolean value.

  • Delete Author – delete author by provided author id and return boolean value. When deleting author you could choose 2 options:

    • set authorId field for corresponding news to null.
    • remove corresponding news.
    Optional

    Think of declarative way of choosing appropriate option instead of imperative way:

    Imperative way: in delete author method load all news related to that author and either set their authorId field to null or remove them.

    Declarative way: use custom annotation (e.g. @OnDelete) with its handler (could be implemented via Aspects).

As well as in the Architecture advanced module all returned and received data should be like DTO type.

The mapping between the dto and the model (domain object) should be done at the service layer using any library. For example: Mapstruct, Modelmapper.

Validation

Validate all the input according to the rules described in DataSource. It can be done by directly implementing all validations in business logic code or declaratively, e.g. via custom annotations.

To support your custom annotations and perform validation outside of business logic code you can use e.g. Aspects.

Module Main

  • Use Command pattern to call operations
  • Instead of direct call module-web from module-main organize communication between module-web and module-main by custom annotations @CommandHandler, @CommandBody and @CommandParam placed in controllers

Testing

  • Cover service layer with JUnit tests.

General requirements:

  1. Code should be clean and should not contain any “developer-purpose” constructions.
  2. App should be designed and written with respect to OOD and SOLID principles.
  3. Clear layered structure should be used with responsibilities of each application layer defined.
  4. All business logic should be written in the module-service: mapping model to dto and vice versa, validation, etc.
  5. All the news and author data should be generated automatically in the module-repository with the amount of 20 and stored in array (database emulation) when the application is running. Reading default data for news and author generation should be from files in resources package, e.g. author.txt, content.txt and news.txt.
  6. Module-web and module-service should accept and return dto objects.
  7. Module-repository should accept and return model objects.
  8. Convenient error/exception should be implemented: all errors should be meaningful. Errors should contain errorMessage and errorCode, where errorCode is your custom code.
  9. Application should be tested and pass all tests suites.

Application requirements:

  1. Java 17 should be used.
  2. Gradle. Multi-module project. Spring.
  3. Application packages root: com.mjc.school.
  4. Java Code Convention is mandatory.

Our solution review:

If you have finished task and would like to see the original solution of it written by our experts, write in #stage-3 channel about it. Access will be provided.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Java 100.0%