Microservice Package, Class, and File Naming Standard

Microservice_Package_Class_File_Naming_Standard.md

Microservice Package, Class, and File Naming Standard

Java File Naming Convention

A Java file must have the same name as the public class it contains, as required by the Java compiler.

Kotlin File Naming Convention

Kotlin files containing a single public class should have the same name as the class, which starts with a capital letter.

Kotlin files containing multiple public classes should have a name that represents the set of contained classes, and the file name should start with a lower-case letter.

Class / Stereotype Naming and Language Standard

Class names have suffixes that correspond to the classes' stereotypes:

• Domain entity -- a name that represents the domain entity, with no suffix. Written as Kotlin data clases.
• Event -- <name_prefix>Evt. Written as Kotlin data classes.
• Function input object -- <name_prefix>Input. Written as Kotlin data classes.
• Function output object -- <name_prefix>Output. Written as Kotlin data classes.
• Data transfer object that can be both an input and an output -- <name_prefix>Data. Written as Kotlin data classes.
• Business function -- <name_prefix>Bf. May be written in Java or Kotlin.
• External service function -- <name_prefix>ExtSvc. May be written in Java or Kotlin.
• Data access function -- <name_prefix>Daf. May be written in Java or Kotlin.
• Event publisher function -- <name_prefix>EvtPub. May be written in Java or Kotlin.
• Flow -- <name_prefix>FlowCore and <name_prefix>Flow. Written in Kotlin.
• Service flow -- <name_prefix>SvcFlowCore and <name_prefix>SvcFlow. Written in Kotlin.
• Architecture class -- a name that represents the capability provided by the class, with no suffix. Written in Kotlin.
• Boot module -- <prefix>BootModule. The name prefix should be based on the scope of initialization and configuration that the boot module is responsible for. Written in Kotlin.
• Service flow assembly -- <service_flow_prefix>SvcFlowAssembly. Written in Kotlin
• Routes -- Routes.kt. Written in Kotlin.
• Handlers -- Handlers.kt or handlers.kt, depending on how the boot architecture uses Spring dependency injection. Written in Kotlin.
• Beans -- beans.kt. Written in Kotlin.
• Application -- Application.kt or application.kt, depending on type of application. Written in Kotlin.

Package Naming Standard

The package structure for a microservice is rooted on a package whose name is the microservice, prefixed by the organization's standard package naming prefix path.

The package hierarchy is described below. The first 5 sub-packages are the most commonly used ones, appropriate when service flows are not complex.

• <package_prefix_path>.<microservice>

  • svcflow -- Used when service flows are simple, in which case it will contain all service flows. May contain all stereotypes, except event classes.

  • event -- Used when the microservice publishes events. May contain the event stereotype.

  • boot -- May contain boot module and service flow assembly stereotypes.

    • <service_flow_or_functional area> -- This is only required when there are many boot modules and it is beneficial to group them by service flow and functional area. May contain boot modules and service flow assembly stereotypes.

  • web -- Used when the application is a REST listener. May contain application, beans, handlers, and routes stereotypes.

  • evtconsumer -- Used when the application is an event consumer. May contain only the application stereotype.

  • domain -- Only required when service flows are complex and there are domain entities that are used across service flows and/or functional areas. May only contain domain entities.

  • <service_flow_name>svcflow -- This is only required when service flows are complex, in which case there will be one of these per service flow. May contain the same stereotypes as svcflow above.

    • <functional_area> -- Only required if the service flow is very complex. May contain all stereotypes, except service flows and event classes.
    • svcflow -- Only required if the service flow is very complex. May only contain the service flow stereotype.

  • <functional_area> -- Only required when service flows are complex and functionality is shared across service flows. One of these may be created for each functional area. May contain all stereotypes, except service flows and event classes.

  • arch -- This will normally be absent, as the architecture is mostly provided as libraries. Only appropriate if there are complex architecture classes that are specific to this microservice.

    • <architecture_area> -- Contains architecture classes.