Reactive Domain

Naming Conventions

Namespaces

As I’ve been going through this educational experience, I’ve tried to come up with a naming convention that makes a little sense. In other projects, I’ve usually started with a ProjectName.Core which held the main business logic for the system being authored. From there, I usually wind up with a ProjectName.Api, a ProjectName.Portal, maybe a ProjectName.Api and a few ProjectName.[Something]Service for backend tasks.

With this exploration, after 3 efforts of kicking something real off, I’ve discovered one change that I’m looking at making ongoing to the system. Logically, ProjectName."Core" holds the logic used throughout the Api, Portal, and [Something]Services, so ongoing, the plan will be to structure as:

ProjectName
This will be the dll for holding the core logic within the system.
ProjectName.Portal
This is the website that you’ll access to interact with the system. There is usually only one dedicated site, but if there winds up to be several, I believe I’ll go one step deeper, and say ProjectName.Portal.[Area of Concern]
ProjectName.Api
These are the APIs your customers (or software clients you’ve built) will interact with your system. As with Portals, if there is the need for having multiple APIs within the solution, again, the naming convention will most likely be ProjectName.Api.[Area of Concern]
ProjectName.Client
Usually, when interacting with an api endpoint, there should be a contract between the API itself with it’s dependent clients. Naming with the ProjectName.Client nomenclature should solidify this concept.
ProjectName.[Something]Service
Backend services, like importing exposures into a gift card platform, cannot execute within the lifetime of

Aggregates

Aggregates are things that describe something represented within the context of a system, such as a BankAccount, GiftCard, Shopping Cart, etc.

Commands

Commands are the instructions of things to do within the system (e.g. CompleteTransaction).

Nomenclature for commands are to describe them as a task that must be done. “Do This”, “Add That”. Describe what you want done as-if you were doing so in the real world.

Events

Events are things that have happened in the system (e.g. TransactionCompleted).

Nomenclature for events are to describe them as the result of a task. “Transaction Completed”, “Item Added”, etc. These are the items within the “ledger” that are immutable in nature.

Command/Event Organization

“Key” Field Namings

Chapters

  1. Naming Conventions
  2. Commands and Events
  3. Process Managers
  4. Centralizing Business Logic
  5. Integration Tests