Tutorial 3: Defining Business Logic Workflows as Domain Models :: Modules

Domain Modelling

Domain modelling here is the process of taking a workflow diagram and defining attributes that tell Visual Studio the intent of objects and data like properties and data types.

Modules

The first, and sometimes hardest step, in modelling is naming modules. Modules are groups of logically grouped operations. An easy example of a module is authorisation. At a minimum, this involves the concept of an object and permissions. Usually that object is a user, but it might be a 3rd party, partner, or even a system such as a scheduled process. So a module will normally have commands, events, handlers and aggregates.

For now we're not going to focus on concepts like authentication or authorisation, but we will create our first module. The name of this module may change over time and may be broken up into more than one module as our model evolves over time. This is to be expected and is normal.

For now we'll create a module named Terminals. This isn't very imaginative, but it does generically cover our ATM and Teller. Later on our system might have concepts for applying for and accept loans.

Creating a Module

• From Visual Studio, create a new Package.
• Name the Package, Terminals.
• From the list of Stereotypes, apply the Module and C# Namespace stereotypes.

Module defaults

Modules all have the same requirements, a series of default, fixed name Packages. These are:

• Commands
• Entities
• Events
• Repositories
  • Queries
    • Strategies
• Services

Create packages for each of these and apply the C# Namespace stereotype to each package.