Manfred Steyer - Enterprise Angular

Over the last years, Ive helped numerous companies with implementing large-scale enterprise applications with Angular.

One vital aspect here is decomposing the system into smaller libraries to reduce complexity. However, if this results in countless small libraries which are too intermingled, you havent exactly made progress. If everything depends on everything else, you cant easily change or expand your system without breaking connections.

Domain-driven design, and especially strategic design, helps. DDD can be the foundation for building microfrontends.

This book, which builds on several of my blogposts about Angular, DDD, and microfrontends, explains how to use these ideas.

If you have any questions or feedback, please reach out at manfred.steyer@angulararchitects.io. Im also on Twitter (https://twitter.com/ManfredSteyer) and Facebook (https://www.facebook.com/manfred.steyer). Stay in touch for updates about my Enterprise Angular work.

Please let me know if you have any suggestions. Send a pull request to the books GitHub repository.

If you and your team need support or trainings regarding Angular, we are happy to help with our on-site workshops and consultancy. In addition to several other kinds of workshop, we provide the following ones:

• Advanced Angular: Enterprise Solutions and Architecture
• Angular Essentials: Building Blocks and Concepts
• Angular Architecture Workshop
• Angular Testing Workshop (Cypress, Just, etc.)
• Angular: Reactive Architectures (RxJS and NGRX)
• Angular Review Workshop
• Angular Upgrade Workshop

Please find the full list of our offers here.

Advanced Angular Workshop

We provide our offer in various forms: Online, public dates, or as dedicated company workshops in English or German.

If you have any questions, reach out to us using office@softwarearchitekt.at.

I want to thank several people who have helped me write this book:

• The great people at Nrwl.io who provide the open-source tool Nx used in the case studies here and described in the following chapters.
• Thomas Burleson who did an excellent job describing the concept of facades. Thomas contributed to the chapter about tactical design which explores facades.
• The master minds Zack Jackson and Jack Herrington helped me to understand the API for Dynamic Module Federation.
• The awesome Tobias Koppers gave me valuable insights into this topic and
• The one and only Dmitriy Shekhovtsov helped me using the Angular CLI/webpack 5 integration for this.

Monorepos allow large enterprise applications to subdivide into small maintainable libraries. First, however, we need to define criteria to slice our application into individual parts. We must also establish rules for communication between them.

In this chapter, I present the techniques I use to subdivide large software systems: strategic design. Its part of the domain driven design (DDD) approach. I also explain how to implement its ideas with an Nx-based monorepo.

DDD describes an approach that bridges the gap between requirements for complex software systems and appropriate application design. Within DDD, we can look at the tactical design and the strategic design. The tactical design proposes concrete concepts and patterns for object-oriented design or architecture and has clear views on using OOP. As an alternative, there are approaches like Functional Domain Modeling that transfer the ideas behind it into the functional programming world.

By contrast, strategic design deals with the breakdown of an extensive system into individual (sub-)domains and their design. No matter if you like DDDs views or not, some ideas from strategic design have proven useful for subdividing a system into smaller, self-contained parts. It is these ideas that this chapter explores in the context of Angular. The remaining aspects of DDD, however, are irrelevant for this chapter.

One goal of strategic design is to identify self-contained domains. Their vocabulary identifies these domains. Domain experts and developers must use this vocabulary to prevent misunderstandings. As the code uses this language, the application mirrors its domain and hence is more self-describing. DDD refers to this as the ubiquitous language.

Another characteristic of domains is that often only one or a few groups of experts primarily interact with them.

To recognise domains, it is worth taking a look at the processes in the system. For example, an e-Procurement system that handles the procurement of office supplies could support the following two processes:

We can see that the process steps Approve Order, Request Budget and Approve Budget primarily revolve around organisational hierarchies and the available budget. Managers are principally involved here. By contrast, the process step is fundamentally about employees and products.

Of course, we could argue that products are omnipresent in an e-Procurement system. However, a closer look reveals that the word product denotes different items in some of the process steps shown. For example, while a product description is very detailed in the catalogue, the approval process only needs a few key data:

We must distinguish between these two forms of a product in the ubiquitous language that prevails within each domain. We create different models that are as concrete and meaningful as possible.

This approach prevents the creation of a single confusing model that attempts to describe everything. These models also have too many interdependencies that make decoupling and subdividing impossible.

We can still relate personal views of the product at a logical level. If the same id on both sides expresses this, it works without technical dependencies.

Thus, each model is valid only within a specific scope. DDD calls this the bounded context. Ideally, each domain has its own bound context. As the next section shows, however, this goal cannot always be achieved when integrating third-party systems.