Doing Science: What I learned while building RouteBastion as a Master’s Thesis project

Pietro — Tue, 17 Jun 2025 01:42:47 +0000

📝 Note: I’m not an academic guru, just a developer navigating the world of research for the first time. Everything in this post comes from what I observed and learned the hard way. Use it as a perspective, not a prescription.

When I decided to build RouteBastion (my SaaS platform for unified VRP solutions) as my Master’s Thesis, I thought the hard part would be the code, and boy, I was wrong.

Entering the world of Academic Research and R&D while coming from a full-time software engineering background was a whole new game. Here's what I learned and what I wish someone had told me earlier.

Searching for Related Work is both easy and hard

Let me break it down for you like I did for my friend Mark:

Sometimes it’s easy: you find papers solving exactly your problem, cite them, highlight your difference.
Sometimes it’s tricky: you find papers solving similar problems, still cite them, but explain the nuances.
Sometimes it’s overwhelming: there are too many directions to explore.

I learned to think of related works in terms of age and citation count:

Paper Type	Action
📅 Very recent (<5 years), no citations	Cite with caution, it's new, might be unstable
📅 Very recent, with citations	Cite, it's gaining traction
📅 Older (>5 years), with citations	Cite, it's validated
📅 Older, no citations	Avoid, there's probably a reason it’s ignored

⚠️ Disclaimer: This table isn't a strict rule or academic standard, it's based on patterns I observed during my research process. Your advisor or field might have different expectations, and exceptions always exist. Use it as a starting point, not a rulebook.

And here’s a tip I picked up from a professor: the quality of your research often depends on the quality of the papers you use as foundation.

Everything needs Scientific Backing

When you're building a product in the real world, you're used to justifying decisions with experience, benchmarks, or “it works.” That doesn't fly in academia.

Want to use gRPC? You better explain why with references or comparisons.
Implemented a caching strategy? Show benchmarks or cite existing work.
Picked Go instead of C#? You need more than a GitHub star count, you need research to back it up.

No evidence = no credibility.

And if no one has done the benchmark you need? Congratulations, now you have to do it.

Nothing can be implicit

One of the biggest mistakes I made in my first paper was assuming that the novelty of my work would be understood by the reader, just because I wrote an ok related work section.

Wrong.
In academia, everything must be explicit.

If your system is novel, say it.
If no one has combined technologies X, Y, and Z in this way before, say it.
Don’t expect the reader to “get it”, tell them.

TL;DR: Assume nothing. Explain everything.

Lessons from my first paper

Some lessons hit hard:

Never leave writing to the last minute, ever: Writing is the research, and it takes way longer than you expect.
Professors are your best search engine: They know how to navigate Scopus, IEEE, ACM, and Google Scholar like pros!
Don’t write “we use PostgreSQL”, write “we use a relational database”: Abstract your tech stack, Academia wants generalization, not product endorsement.

Final thoughts

My journey building RouteBastion has taught me that software engineering and academic research speak different languages, and that translating between them is a skill in itself.

But once you learn the rules, academia becomes a powerful tool to validate your work, communicate it clearly, and make a real contribution, not just to users, but to knowledge itself.

If you're a developer considering a Master's or PhD, I say: do it. But bring citations.

I applied DDD and realized my problem wasn’t the Domain

Pietro — Fri, 13 Jun 2025 00:13:46 +0000

When I started building RouteBastion, a Broker to unify APIs for solving the Vehicle Routing Problem (VRP), I was determined to design it the "right way". Clean code, separation of concerns, rich domain models... Everything! Naturally, I turned to Domain-Driven Design (DDD).

I went deep into DDD: Bounded Contexts, Aggregates, Entities, Value Objects, Ubiquitous language... One can say I was cooking by the (blue) book.

I modeled customers, API keys, vehicles, and even constraints as domain objects. It was elegant, well, at least on paper.

The Real Complexity Wasn’t in the Domain

As the days passed by and I refactored parts of the code, I realized something important: my real complexity wasn’t in the domain, but it was in way I interacted with Cloud Providers.

Being a Broker of APIs means:

Massive requests can eventually come through;
Dealing with quotas and rate limits;
Caching strategies, concurrency, and task queues;
Periodically checking statuses on the external APIs.

The domain part (the "business logic" of who a customer is, or what a vehicle does) is stable, simple, and predictable. What isn’t simple is the Cloud selection algorithm, tuning performance of my database, and designing scalable queue-based execution for solving hundreds of routes in parallel.

What I Learned

DDD shines when business rules are complex and volatile. That’s not the case with RouteBastion. My complexity was mostly technical, not business-oriented. That doesn’t mean DDD was useless, quite the opposite. Here’s how I’ve reframed things:

I still use DDD principles to structure my codebase and isolate concerns;
My core domain is now focused on orchestration of routing solutions (namely external APIs);
Performance, and concurrency are now treated as first-class citizens in my architecture.

That realization led me to offload anything that wasn’t core to my problem space. For example, I used Kong Gateway for the first time to handle things like:

Rate limiting;
Authentication;
Routing.

These were concerns that didn’t belong in my domain layer, they were infrastructure responsibilities. Kong helped me focus on the actual routing orchestration and performance tuning, while still ensuring production-grade API exposure.

Advice for Devs Exploring DDD

If you're on a DDD journey and your domain feels "too simple", ask yourself:

Where does your system’s complexity really come from?
Are you solving a business problem, a technical challenge, or both?
Could your “domain layer” be more about orchestrating processes than modeling behavior?

DDD is a great tool, but like any tool, its value depends on when and how you use it.

Closing Thoughts

Building RouteBastion has taught me to appreciate the separation of domain and infrastructure, but also to recognize when the “domain” isn’t the main actor. Sometimes, you're not building a business system, you're building a high-performance system that serves a business system.

And that’s perfectly fine. Now, I'm slowly refactoring parts of my system to gain more traction for future development.

If you’ve ever wrestled with something related, I’d love to hear your story too.

🤘 Thanks for reading, follow me if you're into DDD, architecture, and solving hard problems with clean code.

Forem: Pietro