Intro

The UpDevs SDK aims to make the life of the developer easier by providing common implementations and enforcing a default project structure. It provides implementations to use the DDD pattern (Domain-Driven Design) as described by Eric Evans in his book of 2003.

Even though certain liberties were taken (like ignoring the rule of not using Application/Domain services as CRUD), the default behavior was maintained. For example, following some more modern concepts by Scott Millett and Nick Tune, we do not use the infrastructure layer to handle persistence. Instead, we use a specific layer (persistence) that should only be accessed by the domain layer. This is the structure we have in place (feel free to add more projects to better suit your organizational patter):

Project name	Description
YourProject.Domain	Holds all business logics. No business logic should be found outside of this layer.
YourProject.Application	Connects the UserInterface layer to the Domain one. It cannot have any business logic, only some data formatting and orchestration of domain services, if needed.
YourProject.UserInterface[.API]	Responsible for exposing data to the consumer of the application. The .API suffix is optional and only used for restful projects.
YourProject.Persistence	Data persistence. Here you can store the entities, validators, mappers and event handlers.
YourProject.Infrastructure	Utilities that provide support to the other layers. For example, sending messages through the network, accessing cloud storages, reading and writing files, etc.
YourProject.Models	Holds all models returned to or sent by the consumer and specific models used inside the application. Suffixes Model 1, Input 2 and Response 3.

A default structure generated for the UpDevs SDK would be like this:

• YourProject.Application
• YourProject.Contracts
• YourProject.Domain
• YourProject.Migration
• YourProject.Models
• YourProject.Persistence
• YourProject.UserInterface[.API]

caution

It was our decision not to implement, at least at the moment, utilities to facilitate development of other specific items of DDD, like Factories and Aggregates. We provide a very powerful domain layer, even allowing domain services to communicate with other domain services, making this functionality not required at the moment, in our opinion. Even though these are not provided by the UpDevs SDK, you can create them yourself.

caution

Another utility defended by DDD and not encouraged by our implementation is the ability to access repositories from the UserInterface layer. This layer should only communicate with the Application layer. This specific functionality, although discouraged, is possible due to GetDomainService being available in the UserInterface layer.

This separation of concerns is also defended by Scott Millett and Nick Tune in their book "Patterns, Principles, and Practices of Domain-Driven Design"

note

Even if the Application layer may seem not necessary for your workflow, we recommend you use it as proposed here. It's important to remember we may not always use a controller to interact with the consumer/user, so having all your formatting/orchestration in the Application layer will improve reusability.

Footnotes

1. Suffix Model

   Inside the Models we can add the classes with suffix Model directly at the root level. You may choose a different approach that better suits your organizational pattern. These classes are used when the same model is used to receive and send data to the consumer. ↩

2. Suffix Input

   Inside the Models we can add the classes with suffix Input inside a folder name Inputs. You may choose a different approach that better suits your organizational pattern. These classes are used to represent the data being sent to the application by the consumer. ↩

3. Suffix Response

   Inside the Models we can add the classes with suffix Response inside a folder name Responses. You may choose a different approach that better suits your organizational pattern. These classes are used to represent the data being sent to the user by the application. ↩