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 React. 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, migrating the interface from React to another framework), 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 (Excel or FASTA — PDF is implemented at the parser level but not yet wired up from this screen). Each file goes through the corresponding parser and becomes a uniform list of probes.
2. Quality control
The quality control engine applies the 8 RF-3.x rules (5 per probe + 3 panel-level) to each probe, combines the results with the 'worst status wins' criterion, 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 render DTO with the same chain of pure functions that feeds the 'Technical detail' trace — without duplicating the calculation — and different components read that same data to show the graph or the technical detail, with the mismatch alerts overlaid as an extra flag, without touching the base drawing.
4. Export
The export feature (RF-5.1) is still an interface mockup: you choose a format and a scope, but the actual file generation is pending.
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.