Field-driven design practice--Serial number generator (next)

0. The previous review

In the previous article we used the test-driven development method (Test-driven Development) to implement a simple serial number generator, and obtained a preliminary software model:

Figure 1 Numbering Generator model (V1)

Familiar with the design pattern of the friends will be able to see at a glance, the use of the combination mode (composite pattern), the number of each child as a serial number to deal with. While this model works, we have a lot of questions to ask:

What's the use of the Iserialnumbergenerator interface? Why not use abstract classes directly (Tserialnumbergeneratorbase)?

Does the customer need to validate the serial number? Should the Validate function return Boolean even if required?

Calling the Nextserialnumber function requires passing in a serial number, does it mean that the caller needs to know the current serial number? Is that appropriate for generator?

Since tconstantcodeserialnumbergenerator represents a fixed code, is it strange to call the Nextserialnumber method?

If you consider adding a date to the serial number, how does this model need to be modified?

...

In addition to these questions, I am afraid that the biggest problem with this model is that it looks more like a technical model-though it can barely work, but does not show any domain knowledge.

Now, we should stop, go back to the starting point and rethink:

What ' s the Problem?

1. Domain knowledge

The problem we're trying to solve is really simple--to get an available number. Numbering is generally composed of several parts (part). For example, the number "RK200901160001" of a storage order contains the following 3 sections:

Code: "RK"

Date: "20090116"

Serial number: "0001"