Contribute to help us improve!

Are there edge cases or problems that we didn't consider? Is there a technical pitfall that we should add? Did we miss a comma in a sentence?

If you have any input for us, we would love to hear from you and appreciate every contribution. Our goal is to learn from projects for projects such that nobody has to reinvent the wheel.

Let's collect our experiences together to make room to explore the novel!

To contribute click on Contribute to this page on the toolbar.

Architecture

The following principles and guidelines are based on Angular Style Guide - especially Angular modules (see Angular Docs). It extends those where additional guidance is needed to define an architecture which is:

maintainable across applications and teams
easy to understand, especially when coming from a classic Java/.Net perspective - so whenever possible the same principles apply both to the server and the client
pattern based to solve common problems
based on best of breed solutions coming from open source and Capgemini project experiences
gives as much guidance as necessary and as little as possible

Overview

When using Angular the web client architecture is driven by the framework in a certain way Google and the Angular community think about web client architecture. Angular gives an opinion on how to look at architecture. It is a component based like devon4j but uses different terms which are common language in web application development. The important term is module which is used instead of component. The primary reason is the naming collision with the Web Components standard (see Web Components).
To clarify this:

A component describes an UI element containing HTML, CSS and JavaScript - structure, design and logic encapsulated inside a reusable container called component.
A module describes an applications feature area. The application flight-app may have a module called booking.

An application developed using Angular consists of multiple modules. There are feature modules and special modules described by the Angular Style Guide - core and shared. Angular or Angular Style Guide give no guidance on how to structure a module internally. This is where this architecture comes in.

Layers

The architecture describes two layers. The terminology is based on common language in web development.

Figure 1. Layers

Components Layer encapsulates components which present the current application state. Components are separated into Smart and Dumb Components. The only logic present is view logic inside Smart Components.
Services Layer is more or less what we call 'business logic layer' on the server side. The layer defines the applications state, the transitions between state and classic business logic. Stores contain application state over time to which Smart Components subscribe to. Adapters are used to perform XHR, WebSocket connections, etc. The business model is described inside the module. Use case services perform business logic needed for use cases. A use case services interacts with the store and adapters. Methods of use case services are the API for Smart Components. Those methods are Actions in reactive terminology.

Modules

Angular requires a module called app which is the main entrance to an application at runtime - this module gets bootstrapped. Angular Style Guide defines feature modules and two special modules - core and shared.

Figure 2. Modules

A feature module is basically a vertical cut through both layers. The shared module consists of components shared across feature modules. The core module holds services shared across modules. So core module is a module only having a services layer and shared module is a module only having a components layer.