How probeMe is built (explained with biology)
This document explains the technical decisions behind probeMe without assuming that you know how to program. The idea is simple: the software is organised almost like a cell, and every design decision has a reasonable equivalent in molecular biology. If you understand how a cell separates its nucleus from the rest of its processes, you will understand why the code is separated the way it is.
You do not need to read this to use probeMe. It is for anyone curious about why it was built this way, or for future technical collaborators who want a quick intuition before diving into the code.
1. The overall architecture: probeMe as a cell
All software has to decide who is allowed to touch what. If any part of the program could modify any other part without restrictions, a small change in one place could break something completely different somewhere else — the equivalent of a mutation in the skin directly affecting how the heart beats, with no control in between.
That is why probeMe is organised in concentric layers, just like a cell:
The "pure" business rules: what a valid Padlock probe is, what a mismatch is, what a closed nick is. It knows nothing about the outside world — not about PDF files, not about screens, not about Lovable. It is pure information, like DNA, which does not "do" anything by itself.
It reads the domain rules and puts them into action: "import a batch", "run quality control". It is the process that translates the information in the nucleus into something that actually happens — like a ribosome translating messenger RNA into a functional protein.
The PDF/Excel/FASTA parsers, the connectors to external databases (MGI, NCBI). They are the "membrane proteins" that decide what can get in and in what form — just as a membrane channel only lets one specific type of molecule through, each parser only knows how to translate one specific file format into the internal language the domain understands.
What you see on screen. It receives signals (clicks, data) and displays them, but it does not decide anything on its own — in the same way that a surface receptor transmits a signal into the cell, but is not the one deciding the final biological response.
The rule that is never broken
In a healthy cell, external signals do not rewrite the DNA directly — they go through a translation cascade (receptor → messenger → machinery → nucleus) before anything changes at the genetic level, and the nucleus does not "know" which specific receptor originated the signal either.
The same happens in probeMe: the Presentation layer never directly decides whether a probe is valid or not — it only asks the Application layer to run the validation, and the Application layer consults the rules that live in the Domain. If tomorrow we completely change the screen (for example, replacing Lovable with another technology), the rules of what makes a Padlock probe valid do not change one bit — they are protected in the "nucleus", oblivious to whatever happens outside.
2. The design patterns, explained with genetics
A "design pattern" is simply a typical solution to a problem that comes up again and again in different programs — like saying that "glycolysis" is a pattern that evolution reuses in very different organisms because it solves a recurring problem well (obtaining energy from glucose), not because every species invented it from scratch.
3. Why errors do not "blow up" the program
A PCR reaction that amplifies nothing (no band on the gel) is not a catastrophic failure of the experiment — it is an expected result, which you record and interpret. The experiment is not cancelled just because one tube did not work; you carry on with the rest and note which one failed and why.
probeMe treats errors the same way. If a probe has an invalid sequence, a mismatch, or a malformed file, that is a piece of result data, not a crash of the program. The whole batch keeps processing, and the error is recorded in the final report alongside everything that did work — in the same way that one failed tube does not invalidate the entire PCR plate.
4. The complete journey, end to end
This is how these pieces combine when you use probeMe:
1. Upload
You upload a batch of files (PDF, Excel or FASTA). Each file goes through the corresponding parser and becomes a uniform list of probes — no matter which format they originally came from.
2. Quality control
The quality control engine applies the 4 RF-3.x rules to each probe, combines the results, and assembles the final report you see in the QC Matrix.
3. Topological rendering
If you ask to see the rendering of a probe, the system builds the drawing step by step, assembles the hierarchical structure of the complex, and translates it into what you see on screen — with the visual alerts overlaid on top without touching the base drawing.
4. Export
If you export a report, that action is encapsulated as a command that can be processed, queued, or retried without blocking the rest of the app.
Throughout this whole journey, the rule from Section 1 is never broken: the screen never directly decides whether a probe is valid — it only asks, displays, and waits for an answer, just as a membrane receptor never decides the cell's full response on its own.
This document is an intuitive guide, not a complete technical reference. For the exact detail of each pattern and its formal justification, see 02-arquitectura-patrones-diseno.md in the project documentation.