Planning Phase

In this section, we will try to build a new Laravel project using the popular nwidart/laravel-modules package.

But before we dive into the code, we need to PLAN what we'll build. The planning phase is hugely important in larger potentially modular systems. Extra time spent at the "whiteboard" minimizes the unpleasant surprises and painful refactorings ahead.

Our Project: University Management System

Here's the initial project description.

University Operations Management Platform

This platform centralizes all key university operations in one system. It replaces scattered spreadsheets with structured, auditable records covering admissions, students, exams, library management, and staffing.

Primary Users

• Admissions Officers: Manage the entire student applicant journey.
• Teachers: Handle courses, schedules, and student results.
• Librarians: Track and manage books, loans, and overdue items.

Core Features

Admissions Management

• Register new applications and record evaluations and feedback.
• Move applicants between pending, accepted, and rejected states.
• Automatically convert accepted applicants into student records.

Course and Enrolment Management:

• Maintain a course catalog and monitor enrolment numbers.
• View student lists for each course to support capacity planning.

Examinations and Grading

• Schedule exams by course and teacher.
• Record and store grades, with historical performance linked to each student and course.

Library Management

• Store complete details for each title, including author, subject, and quantity.
• Add, update, or retire materials while keeping stock levels accurate.
• Issue and track book loans with automatic stock adjustments.
• Record due dates, returns, and overdue follow-ups.

From Project Description to Planning Phase

In short, the system will manage:

• Student Admission
• Exams and Grades
• Library

Notice: In this course, we will not create this full application, but enough to understand the Modular structure, which is the goal of this course.

In real life, such a University Management system may be much more complex, with modules like Curriculum, Timetabling, Room Scheduling, LMS, Research Projects, Grants, Billing/Finances, HR, Payroll, Facilities, and Asset Management. But for this course section, I've simplified the scope to only those three modules listed above, to make it easier to understand.

In this Planning Phase, we need to answer two questions:

1. Is this project suitable for dividing into modules?
2. If the answer is Yes, what would be the modules and in which order should we create them?

Keep in mind that dividing the project into Modules is typically MORE work, initially. So, is it worth it?

To Module or NOT To Module?

Why is this University project a good candidate for modules? Because different parts of those systems work mostly separately, they are used by different people and are almost independent of each other.

• Student Admission is covered by the University Administration.
• Exams and Grades are covered mostly by Teachers.
• And Library is a functionality for, well, Librarians.

Similarly, we can look at separation of the code from the same angle. Here's a pseudo-code for a potential Modules structure:

/Modules
 ├── Admissions/
 │    ├── Controllers/
 │    ├── Models/
 │    └── Views/
 ├── Exams/
 │    ├── Controllers/
 │    ├── Models/
 │    └── Views/
 └── Library/
 ├── Controllers/
 ├── Models/
 └── Views/

So, a developer may work only on the Library module, knowing (almost) nothing about other modules or even their existence.

When NOT to Module?

In many other projects, even if they are large, modularity may not help much, because the functions rely very heavily on each other. Then, developers would still work on multiple modules at a time, which defeats the whole purpose of modularity.

For example, a CMS or e-commerce site where everything interacts through a central Page or Product model. Even if you split it into “Catalog,” “Cart,” “Checkout,” and “Orders” modules, they all depend on the same models, events, and observers. You’ll spend more time figuring out how to share models across modules than developing features.

So, the question you need to answer is this: how independent are different parts of your application, and are there enough clear boundaries? In other words, can separate parts of the app be treated as individual Laravel mini-applications on their own?

Which Modules and in What Order?

Well, I already gave away the answer with the modules list above, right? But let's imagine we don't have that plan yet, and we're looking at a "blank canvas".

You need to decide on the boundaries and dependencies between objects. I prefer to start with a first draft of the DB structure and visualize it. From there, it's often clear which objects can be grouped into a module.

So, in this case, a "draft" DB would look like this:

From here, we can visually divide the tables into groups of related functionality.

Yes, those groups become Modules.

And yes, some DB tables will have relationships with tables from other Modules. On DB level, it's not a big deal, but on the application level, one of the goal is to minimize potential inter-modules inconsistecies.

Also, there may be "core" DB tables that would be related to multiple modules, like "users" or "students", in our example. Those are candidates for the so-called "Core/Common/Shared" module, or may even be taken outside of the Module system altogether, into the common app/ folder.

Finally, you may see DB tables that are "on the edge" as to where to put them. So, you raise questions, like:

• Does DB table X "courses" belong to the Student Admission or Exam module?
• Should the DB table "teachers" have its own module, like Staff?
• etc.

From here, you refine both the DB schema draft and the structure of your Modules. Of course, you don't necessarily need to use the database, but in my experience, this is the easiest way to describe realistically the objects that the project will work with.

And finally, you need to decide in which order you would build the modules. Again, it's similar to DB dependencies: without students, you can't build exam/library functionality for them, right?

So, after a few "thinking iterations", I came up with this plan for how we will build the modules, in the upcoming lessons:

1. "Core" no-module functionality with Users (teachers and other roles)
2. Student Admission Module: applications, students, courses
3. Exam Module: exams, grades
4. Library Module: loans, books

Ok, we've finished the Planning Phase. Now, let's dive into actual coding.