Appendix A. Role of abstractions in domain modeling

 

You should treat this appendix as a prelude to the entire discussion on DSLs. A DSL is nothing but a layer of abstraction over an underlying implementation model. The implementation model is nothing but an abstraction on top of the problem domain model, using the technology platform of the solution domain. Unless you get it right, your domain model won’t be at the correct level of abstraction, and the linguistic representation of it in the DSL won’t be either. Let’s see how you can make your abstractions shine.

A.1. Qualities of well-designed abstractions

This section focuses on the qualities of well-designed abstractions. I’ll use the fields of software engineering and program design as points of reference, but I’ll specifically focus on how having a well-designed abstraction makes it easier for you to design reusable domain models. As we go down this road together, you’ll learn to appreciate how abstractions play a central role in designing complex domain models. As you learn to abstract more and more, you’ll become increasingly proficient at distilling the core concepts of a model from the redundancies of the surrounding details. To illustrate my points, I’ll discuss specific qualities that differentiate well-designed abstractions from poorly designed ones.

A.2. Minimalism publishes only what you promise

A.3. Distillation keeps only what YOU need

A.4. Extensibility helps piecemeal growth

A.5. Composability comes from purity

A.6. References