Skip to content

Latest commit

 

History

History
60 lines (42 loc) · 3.73 KB

diamondArchitecture.md

File metadata and controls

60 lines (42 loc) · 3.73 KB
Raw

Diamond Architecture Motivation

The diamond architecture is based on a set of rules that allow a great degree of flexibility, making it a good choice for project that have to change over time.

Rules

The rules of the diamond architecture are:

  • Have a clear unidirectional dependency graph
  • Keep the dependencies of each module to the minimum
  • Every layer of modules depends on the prior layer
  • Dependencies across the same layer should be avoided

Module Naming Convention

On top of the rules, there are some recommendations about how to name each module. For example, the modules in this project follow the diamond architecture nomenclature: <layer>-<type>-<function>-<library>

Logical Layers

There can be as many layers as needed, but the recommendation is not less than three and not more than six. There are four layers in this project.

Layer Responsibility

01

 API/Interfaces

02

 Common elements

03

 Implementations

04

 Composition of interfaces to run the project

Types of Modules

There can be as many types of modules as needed, but with the following four, most of the cases should be covered.

Type Description

c

 Common modules that share functionality across the project

i

 Input modules that bring data into the project's pipeline

o

 Output modules that process the data and send it somewhere outside the project

u

 Util modules that help modules that share the same underlying library

Functions of Modules

The function of the modules will vary based on the project's needs. In this PoC we used the following

Type Description

configuration

 Load the project's configuration

consumer

 Consumes the data from upstream sources

core

 Holds the business model and logic

dataGenerator

 Generates dummy data (replaces upstream sources)

processor

 Applies the business logic to the data and sends it to the external sinks

Libraries of Modules

Finally, the last tag, libraries, refers to the main library of the given module (when applicable).

For example, the configuration module is simply named as 02-c-config and the flink processor is 03-o-processor-flink because we have multiple libraries used for processing.