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

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