Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Maintainability has to be facilitated on many levels. From naming conventions to the overall architecture. This design guide concerns the latter, and discusses the architecture using the concept of Clean Architecture.

...

Typical example: A Blueriq Project Structure

In Blueriq it is possible to stack modules on each other to reuse elements from lower modules. This enables the use of generic functionality in lower modules, and specializing them in a specific module if changes are needed. These modules should represent business concepts, such as a product being sold. In below structure, the middle layer represents different labels of the company which are similar to each other in most aspects, and therefore use the same generic library. Each of these labels is represented to the end-user using a certain channel. Examples of such channels can be a website or an app on the phone or tablet. For each channel you want to change the behavior of the application slightly so that the user experience is changed to optimally function for that specific channel. This represents the top layer of the structure.

 

Image Removed

The underlying idea why this structure is agile and maintainable is that you can perform changes on the level that fits the change. In case that Label C has a slight variation on the rules, then you would create that logic in the Label C module. In case you want to split up your pages for Channel 2 (as that might be a mobile channel), then you change your flow in the Channel 2 module. If a change should be applied to all applications, then you perform it in the generic base module. When making changes you should consider when functionality should be moved up or down the module structure. You should make functionality more generic (moving down) when similar functionality is implemented in horizontally aligned modules. You should make functionality more specific (moving up) when you notice that each upper module changes the functionality significantly. A common pitfall is to create functionality in the generic layer while it is not generic (yet).

The advantage of this is that small changes could be implemented quickly. The disadvantage of this approach is an undesirable growth of the generic layer which leads to a high number of dependencies through the application landscape.

Small changes usually are:

 

 

...