Moldable Development patterns
A Pattern Language for Moldable Development
Moldable Development is a way to support decision-making by molding the development tools and environment to your problem, thus making the domain concepts visible, explorable, and explainable . For an introduction, see How to get started with Moldable Development.
A good way to learn about moldable development is to focus on the patterns we observe when practicing it. Each of the patterns below addresses a problem to be solved, there are forces at play that motivate the application of the pattern, there is a solution , and steps to implement the pattern. Finally, there are related patterns that may be applied before, during or after the steps.
Overview
![](gt-figures/1515.png)
At the top of the map we have Explainable System, which is not a pattern per se, but rather the goal of moldable development.
An Explainable System is a software system whose internal model has been exposed with the help of numerous custom tools.
Each custom tool requires the existence of a Moldable Tool, which can be cheaply adapted by a simple customization.
Some domains require a preliminary phase of Tooling Buildup, for example, to create dedicate parsers for programming languages, DSLs or specialized data formats, or bridges to other execution platforms. A Blind Spot is problematic part of the target system that is hard to understand and work with, and may be a promising starting point for moldable development to initially engage Stakeholders. A Project Diary is a notebook that serves as a starting point for development tasks. A Throwaway Analysis Tool can be a quick way to solve an urgent problem in a focused way.
Moldable development itself starts with a Moldable Object, a live instance of a domain entity that is explored and molded with custom tools that package the results of exploration tasks. An interesting instance can be encapsulated as an Example Object, essentially a unit test that returns a tested object. An example can be embedded in a project diary notebook page, and can also be used as a moldable object itself for further development tasks.
In case the domain includes already existing data entities, each of these can be wrapped in a Moldable Data Wrapper to produce a moldable object.
A moldable object can be explored with the help of its Contextual Playground, a live programming environment bound to the state of a live instance. Working code can be extracted from such a playground to create custom tools.
The most common of these tools are:
• a Custom View, a dedicated view of an object within a moldable tool such as an object inspector or a code browser, to display or visualize domain-specific information,
• a Custom Action that encapsulates a useful domain action, and
• a Custom Search, to perform an ad hoc query over objects reachable from a given moldable object.
A custom view is frequently a Simple View that can be quickly prototyped, and later extended. A custom search often benefits from a Moldable Collection Wrapper, to allow the results of a query to be also molded with custom tools.
Caveat
This collection of best practice patterns is a work in progress.
Feedback is welcome. See: How to give feedback and contribute