15. But, then a you add "definition " with the name
"Product" (in another file in the same project):
Product{
ProductId:Integer
ProductName:VarChar
ProductPrice:Money
}
17. • The normalization is correct, and the initial input is "more intuitive" for
people not familiarized with normalization rules:
• The developer only needs to think about one particular
view/perspective/transaction at a time
• First the hierarchical structure of the Invoice, pretty much as it appears
from the end user perspective, and then think only about data that
describes a Product, also pretty much as conceptualized by an end
user with no formal training of database normalization.
• This does not mean this is a tool to be used by end users, but it does
means that it is going to be a lot easier for the developer doing the
modeling to use the UbiquitousLanguage to design the database model
(and to validate it with the user)
• Another advantage of this way of describing the databases, is
that the code that was originally written to deal with the
view/transaction "Invoice" is not altered when the
view/transaction "Product" is added to the project, and
therefore the code is not affected by changes in the underlying
structure of the database (multiplicity changes do not have a
damaging ripple effect on the code of the application).
18.
19. If it had a solution it some
one had already fixed it?
void hello(String? name) {
if (exists name) {
print("Hello, ``name``!");
}
else {
print("Hello, world!");
}
}
