Moldable Development patterns
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.
NB: There is also a paper on these patterns in the Proceedings of EuroPLoP 2024, published with ACM (to appear). An arXiv preprint is also available.
Moldable development can be understood in terms of a collection of mutually supporting patterns, in other words, a pattern language, summarized in the figure below. These patterns have emerged over several years of experience in developing GT following moldable development, and applying it to numerous projects.
The diagram illustrates some of the ways in which the patterns support each other: the arrows indicate that one pattern “uses” or “leads to” another. The patterns that are concerned with Tooling are tagged with “(T)”, with Modeling “(M)”, and with the development Process “(P)”.
There are two distinct roles involved in moldable development: (i) the Facilitator is responsible for the technical realization of custom tools, and (ii) the Stakeholder is responsible for the domain model and questions about the domain that should be answered by the custom tools. In a purely technical domain, these two roles can often be played by the same person ( i.e. , a developer), but in general they may be distinct people.
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 domain models have been exposed with the help of numerous custom tools.
Some domains require a preliminary phase of Tooling Buildup, for example, to create dedicated parsers for programming languages, DSLs or specialized data formats, or bridges to other execution platforms. Each custom tool can be seen as an extension of an existing Moldable Tool, which can be inexpensively customized. A Project Diary is a notebook that serves as a starting point for development tasks and recording explanations. An explanation generally takes the form of a Composed Narrative, a story built up with the help of live objects. A Blind Spot is a 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 Throwaway Analysis Tool can be a quick way to solve an urgent problem in a focused way.
At the center of the diagram we see Moldable Object, which is also the most central pattern in terms of methodology. 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:
(i) 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,
(ii) a Custom Action that encapsulates a useful domain action, and
(iii) 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.
The patterns are listed in three sections, starting with Tooling Patterns, and proceeding through Modeling Patterns and Process Patterns. This order reflects the diagram above, and provides a complete picture of all the patterns. The hasty reader might prefer to start directly with Moldable Object at center of the diagram, and from there follow the arrows to the other patterns, the most fundamental being Example Object, Contextual Playground, and Custom View. This will provide a quick introduction to the most central and essential of the moldable development patterns.
This collection of patterns is a work in progress.
Feedback is welcome. See: How to give feedback and contribute