Evolutionary architecture and emergent design: Using DSL

Introduction: So far, evolution architecture and emergency design focus on the emergency design of the technical model, this period will introduce the use of specific domain language (DSL) capture domain idiomatic patterns. The series author Neal Ford illustrated the method with an example that shows the advantage of this abstract style of acquiring idiomatic patterns.

Idiomatic patterns can be either technology or domain. The technology model identifies solutions for commonly used technical software issues, such as how validation, security, and transaction data is handled in an application (or application suite). The previous installments focused on techniques used to acquire technical idiomatic patterns, such as meta programming. Domain mode is concerned with how to abstract common business problems. While the technology model appears almost in all software, the difference between domain modes is as large as that between business. Yet acquiring them is a rich set of technologies, and this is the topic that will be discussed in the current and subsequent installments.

This article provides the power to use DSL technology as an abstract style to get a domain pattern, and DSL offers a variety of options, including its own named pattern. A recent book by Martin Fowler A more in-depth study of DSL technology. In subsequent installments, I will use many of his schema names, and his examples will be used in my example to step through the specific techniques.

The motives of the DSL

Why do we have to do so much to create a DSL? Just to get a idiomatic pattern? As I noted in "Using reusable code, part 2nd," The best way to differentiate idiomatic patterns is to make it look different from other code. This visible difference is the most direct clue, and you don't need to look at the regular API. Again, one of the purposes of using DSLs is to write code that doesn't look like the source code and more like the problem you're trying to solve. If you can achieve this goal (or close to that goal), you will fill this void in your software project and bridge the gap between developers and business stakeholders. It is necessary to allow users to read your code because it eliminates the need to translate code into language, which is an error-prone task. Make your code readable for non-technical people because they understand the software's intended assumptions so that you can communicate more with each other.

To motivate developers to use this technique, I'll borrow examples from the Fowler DSL book. Let's say I'm working for a company that makes software-controlled secret compartments, thinking about James Bond. One of the company's clients, Mrs. H., wanted to put a dark lattice in her bedroom. Our company, however, uses the java™-driven toasters left by the. com bubble to run the software. Although Toasters is cheaper, the software is expensive to update, so I need to create the underlying dark code, set it permanently on toasters, and then find a way to configure each user's needs. As you know, in the modern software world, this is a very common problem: general behavior does not change often, and configuration needs to change according to personal circumstances.

H. Madam wants a dark lattice, the way to open the dark lattice is: first close the bedroom door, then open the second drawer of the dresser, and finally open the bedside lamp. These activities must be carried out sequentially, and if the order is disrupted, it must begin again. You can think of the software that controls the shadow as a state machine, as shown in Figure 1:

Figure 1. H. Lady's dark Lattice is the state machine