Domain Prototyping
UI Prototypes
In web development, “prototyping“ normally refers to a UI prototype, which serves as a template for the actual UI implementation. In my opinion, this approach is not very efficient:
- Creating a UI prototype is expensive, but it can be used only for the initial UI implementations.
- Changes have to be done either twice — on the prototype and on the actual implementation, or the prototype becomes worthless. This is not compliant to agile processes.
- The business domain and the UI cannot be decoupled completely. Therefore changing the business domain always requires changing the UI too, which is again not very agile-friendly.
- UI prototyping often focuses only on the design of expected states, with important edge cases emerging later and not being addressed by the initial UI prototype.
Tackling complex domains
UI prototyping is fine in a lot of use cases. But if the most complex aspect of a web application is the business logic rather than the UI, it does not help to solve the critical parts of the project. In this case, I like to focus primarily on the business domain and apply Domain-Driven Design (DDD). But how can we implement the business domain with a compliant UI in an agile way? My suggestion is “Domain Prototyping”, which I define as follows:
Initially focus on the business domain only. Generate all other aspects of your application in a way, such that no efforts are lost. These generated parts of your application can be overwritten with application-specific implementations. The process is applied on at least a REST API and a web UI.
Domain Prototyping supports optimizing the business domain, and thus also the API and the UI in an agile way, while other problems with standardized solutions are neglected. These problems, like infrastructure, integration or security, as well as API and UI customizations, can be added later without the necessity of a refactoring or throwing initially created artifacts away.
Process
A sample process of Domain Prototyping contains of three phases, each one consisting of one or more simultaneous iterations:
- As suggested by the DDD community, start with workshops where the business domain is elaborated. Domain Prototyping allows you to create a fully working application right after the workshop, which can be discussed and accepted by stakeholders as iteration artifact. As normal in agile processes, these discussions serve as basis for further workshops and implementation iterations.
- Once the business domain is such mature that stakeholders do not expect significant changes anymore, start finalizing the domain code including unit testing. In the same time, UI developers start implementing individual UI components that match the business domain models. These components replace the Domain Prototype components.
- While the UI is finalized, additional backend aspects like infrastructure, integration or security are treated.
HATEOAS Navigator
Remember my definition of Domain Prototyping. The developers shall focus on the business domain only, all other parts shall be generated, but replaceable later. A very well known framework that allows this in the backend, is Spring Boot, that auto-configures missing parts of the configuration with reasonable default values. Spring Data Rest even goes to the point, that all you have to do is implementing your business domain, it then generates data persistence and a REST API. In my opinion, you should never go to production with pure Spring Data Rest, there will be better ways to secure your application, improve your API and especially the way how your data is persisted. But it is a good starting point, and Spring Boot makes it easy, to subsequently replace its default configuration with your own, and this is exactly what Domain Prototyping is about.
When it comes to the UI, you have to decide to go for a simple but stable static markup delivered by the backend or a complex single page application that can deal with the generated REST API. This decision is not part of this article, so let us just go for the latter. I do not know any framework that fulfills the requirements of Domain Prototyping. This is why I implemented two Angular libraries, hateoas-navigator and document-components, that help in creating a sample UI without having any knowledge of the business domain.
hateoas-navigator is the core library which reads different formats of API metadata. The first milestone of the library supports the metadata generated by Spring Data Rest, i.e. HAL, ALPS and JSON schema, plus manual configurations that override the API metadata. For simplicity, the metadata formats shall not be discussed further, this will be part of a later article.
The API metadata is prepared by hateoas-navigator such that it can be consumed through generic interfaces, hiding implementation details. The library provides an interface to the backend business object, and does not only deal with the REST API and dependent aspects like caching, but also describes the business objects’ properties, its validation rules and how the objects can be represented as forms.
While hateoas-navigator provides Angular services for fetching resources and their descriptors, document-components helps to display the REST resources generated by hateoas-navigator. It generates navigation and routing for the REST resources and also creates views for listing, editing, creating or deleting resource items. The components can be overwritten by custom components, just like in Spring Boot.
Evolution
This sample architecture makes Domain Prototyping real: As the video below shows, you immediately prototype your business domain and gain an application that allows testing your domain. And both — backend and UI frameworks — allow overriding the default configuration step by step, until Spring Data Rest and document-components are actually obsolete and can be removed. This possible evolution shall be shown in a future article, as well as the discussion of hateoas-navigator’s architecture, project state and main features.
