Skip to content

Client module

The Departments service provides a Client Module for other services that need to integrate with Department, can do it easily.

The DepartmentClientModule provides a materialized representation of a Department, the DepartmentView. Also, it brings to the table an internal API that maintains up to date the Department Metadata with the changes made on the Department Service.

Currently, the DepartmentView includes:

  • Department correlation id.
  • Department display name.
  • Department code.
  • Parent Department correlation id (if any).
  • Parent Department (if any).

How to use it

The main idea behind the DepartmentClientModule is that, when you create your own entity (i.e ServiceOrder), you can add relations to DepartmentView, which is provided by the module.

The DB structure is included as your own service's migrations, and it is handled as another regular entity. The only difference is that we can share the class and it's mapping so that you don't need to write them.

Defining an Entity with a DepartmentView

First we need to reference the DepartmentsClientModule's Abstraction assembly from our Domain layer.

XML
1
<ProjectReference Include="$(ServicesPath)Departments/ITsynch.Suite.Departments.Abstractions/ITsynch.Suite.Departments.Abstractions.csproj" />

This will allow us to create an entity which has a Department:

C#
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
using ITsynch.Suite.Departments.Domain;

namespace ITsynch.Suite.ServiceOrders.Domain
{
    public class ServiceOrder : BaseSagaStateMachineInstance
    {
        // [..]
        public DepartmentView Department { get; private set; } = null!;
    }
}

We then need to add an EntityTypeConfiguration for this entity on our Persistence layer as usual:

C#
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
namespace ITsynch.Suite.ServiceOrders.Persistence
{
    internal class ServiceOrderConfiguration
        : IEntityTypeConfiguration<ServiceOrdersDbContext, ServiceOrder>
    {
        public void Configure(EntityTypeBuilder<ServiceOrder> builder)
        {
            // [..]
            builder.HasOne(x => x.Department)
                .WithMany()
                .IsRequired()
                .OnDelete(DeleteBehavior.NoAction);
        }
    }
}

After doing that, we must reference and configure the DepartmentsClientModule on our Application Module before we can generate migrations.

Configuring the Application Module

First, we need to reference the DepartmentsClientModule's assembly from in our Application layer project:

XML
1
2
<ProjectReference
    Include="$(ServicesPath)Departments/ITsynch.Suite.Departments.Client/ITsynch.Suite.Departments.Client.csproj" />

Then we need to depend on the DepartmentsClientModule and also configure the DbContext where we want the Department Metadata entity added to. This is usually the only DbContext that you have, which is the one generated by the microservice template:

C#
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
public class MyServiceApplicationModule : SuiteAspNetApplicationModule {

    public override void SetupModule(IModuleBuilder builder)
    {
        builder.DependsOn<DepartmentsClientModule, DepartmentsClientModuleOptions>(
            opts =>
            {
                opts.SetDbContext<ServiceOrdersDbContext>();
            });
    }
}

This is all that you need in order for the module to register the EntityTypeConfiguration for DepartmentView against the DbContext you've just specified.

We can now generate migrations for our service as usual, and we should see the one to one relation we just added, and the table for DepartmentView being created.