Building a library VII - Boundaries
When writing a library, boundaries is something we have to consider. If they are not set, it can quickly get out of hand, with hooks from the outside world pulling your internal code in all directions.
A boundary is where the library starts and stops. A clean boundary means any code consuming the library doesn’t need to know about the inner workings of the library, and vice versa.
Identifying boundaries
Natural boundaries tend to run along the lines of domains, and are normally a good choice. If no natural boundaries are found, you might have to discover some.
The thing to keep in mind is that boundaries are identified by responsibilities. The moment you come across functionality that you no longer wish to take care of, you have hit the edge of a boundary.
For our form library we have an excellent example in how we handled fields. The way we implemented fields, the library has no need to know about the fields are rendered visually, doesn’t know about how validations are implemented and doesn’t know about the content of error messages or how the error messages arrived in the first place.
Likewise, a reagent or React component has no need to know about our form library. They just execute what they have been told to do, with none the wiser what kind of code is using them.
Discovering boundaries
In the event you are treading new ground, where there is little or no knowledge on where boundaries in a domain lie, you will have to take a deep dive into the domain in order to require enough knowledge to identify boundaries. This can be a non-trivial task, as a lot things are deceptively simple looking, but once you dive in you found there to be a lot of complexity hidden underneath.
In these situations my advice would be to start with pen and paper. Sketch a solution, and then start explaining what it is you do. To yourself first, and then someone else. If you can’t find someone else to explain to, use a rubber duck.
Rinse and repeat until you feel you have a pretty good grasp how to implement a solution. Be prepared to go back to the drawing board if it doesn’t work out.
Also… every now and then, revisiting a library and doing a re-write can be a good thing. The aquired domain knowledge in writing a library in the first place gives a better understanding of the problem, and so a second attempt will almost always work out better.
Next up…
We will continue with taking a deep dive into functional zippers, data and how we can use this to bring about advanced rendering options.
