DEV Community

Didier José Torres Parodis
Didier José Torres Parodis

Posted on

Business Logic + Data: the real leverage behind software engineering

#database #softwareengineering #systemdesign #dataengineering

Gap 1

One month ago, a professor from my Platform-Oriented Development course asked me to build a project. I called it Deluxe: a nightclub reservation system.

From the very beginning, I didn’t think in terms of code — I thought in terms of the system as a whole: concurrency issues, APIs, and most importantly, the data model.

With that in mind, I structured my approach:

Steps:

  1. I analyzed the business logic.
  2. I designed the relational data model.
  3. I defined the query set that represents the backend behavior.

At that point, my next step wasn’t reading official documentation. Instead, I focused on planning: setting up my environment, selecting tools, and structuring how the system would evolve.

The result?
The system fulfilled all the requirements — not because of the framework or the language, but because I understood the business logic behind it.

Gap 2

At that point, I realized something: building the system wasn’t enough. I needed to expand its scope into something more meaningful — something analytical.

That’s when Neo4j became the key.

I wanted to introduce dynamic pricing, but not in a naive way. To do that properly, I needed to understand relationships between customers — something that a relational model cannot express efficiently.

So I defined a set of strategic questions:

  • Which customers always attend events together?
  • Who is the most influential client in the network?
  • If a key client doesn’t show up, who else is likely to be affected?
  • Which clients act as bridges between different social groups?
  • What events should I recommend based on social connections?

And the most important one:

If I launch a promotion for a specific client, how many other clients will I reach indirectly through their social network?

This is where the problem becomes clear:
PostgreSQL can store the data, but it cannot answer these questions efficiently.
Neo4j, on the other hand, is built exactly for this type of problem.

From intuition to implementation

To answer these questions, I had to redesign part of my architecture.

1. Synthetic data generation

I started by generating synthetic data based on my relational database.

But I quickly ran into a common mistake:
creating data without respecting real-world behavior.

User behavior is not rigid — it’s noisy, probabilistic, and context-dependent.

So instead of generating uniform data, I modeled:

  • recurring groups of friends
  • VIP clusters
  • occasional visitors
  • users who introduce new people
  • irregular attendance patterns

This allowed the dataset to reflect realistic social dynamics.

2. From relational model to graph model

Next, I designed a Neo4j graph schema derived from a data mart built on top of the original relational database.

  • Nodes: Customer, Event, Reservation

  • Relationships:

    • ATTENDED
    • RESERVED_WITH
    • CONNECTED_TO (inferred social relationships)

This transformation is essentially an ETL process, where:

  • The relational database acts as the source of truth
  • A curated data mart serves as an intermediate analytical layer
  • Neo4j becomes the serving layer for graph-based queries

3. Applying a Medallion Architecture mindset

To structure this properly, I followed a simplified Medallion Architecture:

  • Bronze layer: raw transactional data (PostgreSQL)
  • Silver layer: cleaned and structured data mart
  • Gold layer: graph model in Neo4j optimized for analytics

4. Querying the graph

With the graph in place, I implemented queries using Cypher and graph algorithms:

  • Community detection (Louvain)
  • Influence ranking (PageRank)
  • Bridge detection (Betweenness Centrality)
  • Recommendation systems (graph-based filtering)
  • Path analysis (shortest path, reachability)

What would require complex recursive queries in SQL becomes simple and expressive in Neo4j.

Conclusion

This project changed my perspective.

At first, I thought I was building software.
In reality, I was modeling a business.

The difference is critical:

  • Software implements logic
  • Data represents reality
  • But business logic gives meaning to both

Neo4j didn’t just improve performance — it expanded what was possible to ask.

And that’s the real shift:

The value is not in the system itself, but in the questions it enables you to answer.

The future is not in software.
It’s in understanding the business through data.

Top comments (0)