In the previous article about the backend architecture, we saw how we can split the functionality of the application into several bounded contexts — separately deployable groups of functionality for the backend. The same reasoning about splitting the application applies to the frontend, so we can draw the following component diagram based on the discussion of the backend:
In the Angular framework, bounded contexts can be represented by modules, where each module would represent a bounded context. These modules can be set up to lazy load, which helps with the initial loading of the app to load only the immediately required functionality and makes the app seem to load faster.
The downside of simply using Angular modules for the bounded contexts is the expectation to be able to separately deploy and version the different contexts, yet have them all work together. By creating them as Angular modules, we’re having to build them all at the same time and embed them into one Angular app. The separation of the individual components is therefore lost.
Manfred Steyer has an interesting summary of the various mechanisms to implement micro-frontends and their advantages and challenges.
In my mind, the optimal solution would be one where the implementation for each bounded context is independent of and can be deployed independently from any others, with any functionality or elements shared between multiple contexts shared in a separate library, as a shared kernel in DDD speak.
Looking at the table in the article under the headline “Evaluation,” we see that separate/ independent development and deployment is possible for a few approaches , with “using iframes” and “loading different SPAs” being the most appealing. The bad part of loading different SPAs, or multiple copies of the same framework if we stick with only one version of Angular, is the massive amount of data loading we’re going to be doing. Ideally, we’ll load the framework only once and not multiple times.
On the other hand, if we put emphasis on small deployment size, we end up with the drawback of having to do a build of the entire Angular application when we deploy a new version of any bounded context. The build times could be significant for a large application, which would benefit most from this DDD treatment and the separation in to bounded contexts.
The path I’m going to investigate later in this series is to build various Angular libraries as npm modules — one for each bounded context and store the built artifacts in npm as versioned packages.
This would allow for good encapsulation, as we can define an access control layer (ACL) approach in our library to only expose the functionality and interfaces that we want other modules/libraries to use and know about. It would take the form of an Angular service to assure that we only have one instance of the ACL globally when using Angular’s dependency injection mechanism. The current thinking on how the ACL would talk to the various pieces within a bounded context would be through Rx.js, as its event-driven paradigm of hot observables fits nicely with the sought abstraction, encapsulation and decoupling.
This micro-frontend approach will become particularly interesting in the case of the editing of trip days, as on that page, according to the wireframes, we’ll use visual building blocks from two different bounded contexts on the same page at the same time — trip information and image information. If I had to pick an initial approach, Angular’s potential to support multiple router outlets in one component template would potentially be a feasible approach for this case.
Let’s take a look at the following class diagram, which groups the classes into their respective bounded contexts:
AuthenticationContext, we have the login component providing the login form, as well
AuthService. As discussion previously, this AuthService could be imported in every
other component to check the login status of the user, and also mentioned earlier was the use
of JSON Web Tokens (JWT) to permit the validation of an authentication user without a query
to the backend.
Left out from this bounded context for clarity are other components belonging to an
AuthenticationContext, such as password reset.
Focusing on the trips context, we see at its root how the
TripOverviewComponent uses the
AuthService to assure that the user has access to the data. The trip overview is using two
other components, the
TripCatalogMapView to render the same data
for a trip in the two different presentations seen in the wireframes — in a map view and list
It is, however, the
TripOverviewComponent which will contain the logic to grow and shrink the
two display components depending on user input.
When the user selects a trip from the list or the map, we swap the entire
via the router to show the
TripComponent, which will display the travel route taken as well
as the content the user wrote for that travel day, or
Once the user has selected a trip to view, we continue by rendering the
gets an instance of the
TripSegmentComponent injected , which in turn has access to
TrimpImages and a
This arrangement of Angular components for the display of a Trip permits us to separate the concerns of rendering the trip summary and content from the display of the taken travel route on a map and the respective images associated with that travel day.
Here we also see again the introduction of a
TripImageComponent, which will reference
images from the
ImagesContext and permit the
display of images with custom captions, similar to the
TripImage class in the backend.
Since we’re displaying data that is specific to a user, we need to provide an authentication and
authorization mechanism. What’s more, we need to make sure on every API request that the
user has access to the data requested. In order to accomplish this behavior in an efficient
manner, Angular provides
HttpInterceptors, which are a kind of middleware that sits
- between the creation of an HTTP request and the actual request being sent over the web and
- between the response coming in and being passed to the Observable from the HTTP request
Thus, these interceptors are a prime candidate for handling the authentication by augmenting
every HTTP request with an authorization token or session ID and also listening for custom
headers being set by the server which might have an effect on the behavior of the application.
I will explain the
Interceptor concept in an upcoming post in my blog, together with developing
some code examples of how this could be implemented.