.1
and usage data rather than an association between a customer and their usage
right ( Figure 2.67 ). Bear in mind that, in the domain knowledge model, there is no
right or wrong, only a better or worse.
The block route is a loner. That ??™ s possible too. Not every block has to necessarily
participate in an association. In other words: We should never force a relationship
onto something. The area around route is incomplete yet in our system, since we
haven ??™ t analyzed the navigation system in depth yet.
The RouteKind is a so-called enumeration ( Figure 2.67 ). We use this type if
the number of values for an attribute is limited from the domain perspective. The
attribute type in the block route is an example of this type.
A generalization is another possible relationship in the domain knowledge
model. However, it is not required in our example. If you come across a potential
generalization you should check whether or not the matter could be modeled
more meaningfully with an enumeration type ( Figure 2.68 ).
Eventually, what makes sense and what doesn ??™ t is largely decided by your environment:
Which variant is better understood, especially by the domain people?
Multiple inheritances are absolutely legal and meaningful in the domain
knowledge model, as opposed to the system design where they don ??™ t make sense.
Pages:
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240