223
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
You can use this class as a type in
any entity or value object, as for the following
CardType
:
Enumeration
class:
public
class
CardType
: Enumeration
{
public
static
CardType Amex =
new
(
1
,
nameof
(Amex));
public
static
CardType Visa =
new
(
2
,
nameof
(Visa));
public
static
CardType MasterCard =
new
(
3
,
nameof
(MasterCard));
public
CardType
(
int
id,
string
name)
:
base
(id, name)
{
}
}
Additional resources
•
Jimmy Bogard. Enumeration classes
https://lostechies.com/jimmybogard/2008/08/12/enumeration-classes/
•
Steve Smith. Enum Alternatives in C#
https://ardalis.com/enum-alternatives-in-c
•
Enumeration.cs.
Base Enumeration class in eShopOnContainers
https://github.com/dotnet-
architecture/eShopOnContainers/blob/dev/src/Services/Ordering/Ordering.Domain/SeedWork/E
numeration.cs
•
CardType.cs
. Sample Enumeration class in eShopOnContainers.
https://github.com/dotnet-
architecture/eShopOnContainers/blob/dev/src/Services/Ordering/Ordering.Domain/Aggregates
Model/BuyerAggregate/CardType.cs
•
SmartEnum
. Ardalis - Classes to help produce strongly typed smarter enums in .NET.
https://www.nuget.org/packages/Ardalis.SmartEnum/
Design validations
in the domain model layer
In DDD, validation rules can be thought as invariants. The main responsibility of an aggregate is to
enforce invariants across state changes for all the entities within that aggregate.
Domain entities should always be valid entities. There are a certain number of invariants
for an object
that should always be true. For example, an order item object always has to have a quantity that must
be
a positive integer, plus an article name and price. Therefore, invariants
enforcement is the
responsibility of the domain entities (especially of the aggregate root) and an entity object should not
be able to exist without being valid. Invariant rules are simply
expressed as contracts, and exceptions
or notifications are raised when they are violated.
The reasoning behind this is that many bugs occur because objects are in
a state they should never
have been in.
224
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
Let’s propose we now have a SendUserCreationEmailService that takes a UserProfile … how can we
rationalize in that service that Name is not null? Do we check it again? Or more likely … you just don’t
bother to check and “hope for the best”—
you hope that someone bothered to validate it before
sending it to you. Of course, using TDD one of the first tests we should be
writing is that if I send a
customer with a null name that it should raise an error. But once we start writing these kinds of tests
over and over again we realize … “what if we never allowed name to become null? we wouldn’t have
all of these tests!”.
Dostları ilə paylaş: