The idea of modularity gets thrown around a lot, especially in the space of clean and structured code. It’s one of those ideas that’s just supposed to implement itself if you repeat it enough in a sentence.

When it comes to Angular, achieving modularity is more than just containerizing your code. When we start coding or learning how to use Angular, we often jump in head first — YouTube-tutorial-styled and right into the deep end. If it works, it works, and we often just leave it at that.

However, modularity is the embodiment of a thinking process. These thoughts and processes trickle down into the code that it’s supposed to represent.

So how do you think in a modular manner when it comes to Angular?

Start With the Problem Domain

The issue many developers face is the lack of understanding of what code really is by business owners and managers. To them, code is an intangible concept that exists with a mysterious aura. It is also an ends to a means — with the ends often starting without defining what the means are.

A problem domain is a definition of what you need in order to solve a particular issue. It is a scope for your work, a clear boundary line around what is relevant and what is not. It is the thing that gives us Point A and Point B — the software produced is the connecting line between these two points.

When we don’t have a clear problem domain, we don’t have a clear picture of where we want to go with our code or how to build things. It’s like constructing a house without the architectural plans and just giving the builders some wood and tools to work with. You may end up with a house, but the structural integrity of the building will not be at the same level as one built with a plan and on spec.

When we start with the problem domain, we are able to identify each component in a system and abstract them out as necessary.

But how do we define a problem domain? Let’s take a look at the hypothetical example below.

Presenting Our Fake Business: Gym Monkeys

Your friend Andy needs a gym membership system. He knows that he wants members to be able to sign up online, enter their details and then book in an induction. He also wants gym instructors to be able to access member details and set up nutrition and training plans for a member’s training program.

Members can only access their own information and no one else’s. There is also an admin that is able to add gym instructors in as staff.

On the surface, this sounds like a rather simple and basic system — however, it can grow to be unnecessarily complex if it’s not structured with clear domains. In the brief above we are able to identify two things: roles and actions.

There are three roles — admin, members, and gym instructors. There are also four main actions — the ability to sign up, book an induction, access details, and set up plans.

Let’s take a look at them in a visual format.

Now that we have all the necessary components laid out, it’s time to create relationships between them.

The problem domain is essentially the reason why we’re building our software. In this case, it’s to create a system that can handle and translate Andy’s ideas. What we’ve done here is change the format of Andy’s description of the problem domain into a systematic approach toward visualizing what the connectors between points A and B look like.