TAP_PL_05_Functional Domain Modeling

Prévia do material em texto

Functional Domain Modeling
A domain model is a blueprint of the relationships between the various entities of the problem
domain. Many approaches to domain modeling exist. Functional Domain Modeling will use
functions as the main abstraction to model domain behaviors and abstract data types as the main
abstraction to model domain entities and value objects.
1. Domain Modeling with Types
Although each domain model is different, many common patterns occur repeatedly.
1.1. Simple values
These are the basic building blocks represented by primitive types such as strings and integers.
But note that they are not actually strings or integers. A domain expert does not think in terms of
int and string , but instead thinks in terms of OrderId and ProductCode concepts.
The concept of opaque type and extension methods will be used to model simple values.
1.2. Product Types
These are groups of closely linked data, much like the fields of a table. For instance, a Client
will have several characteristics, such as a Name, Address, etc.
The concept of final case class will be used to model product types.
1.3. Sum Types
Sum types represent a choice in our domain. For instance a Request can be an Order or a Quote.
The concept of sealed trait will be used to model sum types. In Scala 3, the concept of enum
can also be used to model sum types.
1.4. Processes
Processes which have inputs and outputs.
The concept of function will be used to model processes.
2. Domain Modeling Exercise
The exercise is a model of a part of a vending machine. The vending machine takes in a sum of
money to buy a product. Based on the received money and the price of the product, if the
received money is less than the price of the product, the machine must emit a domain error,
1
otherwise the vending machine must emit change. The process of emitting change is based on
the quantity of each currency denomination which is inside the machine. If the change cannot be
delivered, either by insufficient currency in the machine or inability to produce exact change, a
domain error must be created. The return of the successful change process will be a set of
quantities of each denomination, which produces the exact change.
 Model the process of giving change, based on the quantities of each currency denomination
inside the machine, the inserted money and the product’s price. The process must return either a
domain error or the quantities of each denomination which represents the exact change.
The expected result is a model of the domain, in which impossible states are not representable
(e.g. negative money), as well as the process of producing correct change or correct domain
error.
2.1. Exercises
a) Simple type Money
Define the Money concept and associated operations, using the TODO instructions on the project. There
are tests for each of the needed operations. Note that the tests might not pass until the whole project
can compile.
b) Simple type Quantity
Define the Quantity concept and associated operations, using the TODO instructions on the project.
There are tests for each of the needed operations. Note that the tests might not pass until the whole
project can compile.
c) Simple type Denomination
Define the Denomination concept, using the TODO instructions on the project.
d) Change Calculation Process
Implement the process of calculating change in the vending machine service, using the TODO
instructions on the project. There are tests for the process. Note that the tests might not pass until the
whole project can compile.
2
	Functional Domain Modeling
	A domain model is a blueprint of the relationships between the various entities of the problem domain. Many approaches to domain modeling exist. Functional Domain Modeling will use functions as the main abstraction to model domain behaviors and abstract data types as the main abstraction to model domain entities and value objects.
	1. Domain Modeling with Types
	Although each domain model is different, many common patterns occur repeatedly.
	1.1. Simple values
	These are the basic building blocks represented by primitive types such as strings and integers. But note that they are not actually strings or integers. A domain expert does not think in terms of int and string , but instead thinks in terms of OrderId and ProductCode concepts.
	The concept of opaque type and extension methods will be used to model simple values.
	1.2. Product Types
	These are groups of closely linked data, much like the fields of a table. For instance, a Client will have several characteristics, such as a Name, Address, etc.
	The concept of final case class will be used to model product types.
	1.3. Sum Types
	Sum types represent a choice in our domain. For instance a Request can be an Order or a Quote.
	The concept of sealed trait will be used to model sum types. In Scala 3, the concept of enum can also be used to model sum types.
	1.4. Processes
	Processes which have inputs and outputs.
	The concept of function will be used to model processes.
	2. Domain Modeling Exercise
	2.1. Exercises
	a) Simple type Money
	b) Simple type Quantity
	c) Simple type Denomination
	d) Change Calculation Process