Revisiting Domain-Driven Design - part 1

Introduction

A few years ago, I was asked by one of my clients to create a couple of portals using open-source technologies. The goal was to enable the client to continue development without incurring licensing costs.

The main requirement was to deploy the portals in the Azure Cloud and implement a single sign-on feature for users.

A UI designer provided some screens for the portals, but there was no detailed business requirement document or information on how the business operations would be carried out.

To meet these requirements, I decided to use Angular on the front end and NodeJS with Express on the server side, implementing an API layer and utilizing a SQL Server database.

I developed a proof-of-concept application from scratch within a month. After presenting it to the client, I received approval to proceed with the implementation.

Building the application from scratch involved several tasks:

- Implementing authentication using the MSAL library as an HTTP Interceptor on the client side and passport authentication on the server side, utilizing Azure B2C for single sign-on, and incorporating roles into JWT via Claim Exchanger and custom policies.

- Creating NodeJS shared libraries as NuGet packages to handle common tasks such as exception handling and logging.

- Establishing a service layer and adding a cache layer using SubjectBehavior from the rxJs library.

- Implementing CSS using SaaS and inherited variables.

- Initially using Bootstrap CSS and later transitioning to Angular Material.

- Creating server-side controllers and routes in a generic manner.

- Implementing the repository pattern on the server side.

- Developing a library to handle database queries.

- Creating DTO objects and mapper classes.

- Implementing single sign-on.

- Discussing the business requirements, and designing the portal pages and business workflows for both portals.

- Designing the database.

- Setting up development and staging environments in Azure, implementing a CI/CD pipeline, and conducting thorough testing of the portals.

Throughout this process, I received assistance from two full-time developers and three rotating students.

I coordinated the project plan and had regular discussions with the development director every three months. All the work was successfully delivered within nine months from the start date. Unfortunately, the company had to halt all projects due to the onset of the COVID-19 pandemic the day after the project was completed.

A few years later, I was called back to implement a "Commissions" module for the portals.

Continuous Learning and Integration

Recently, I had the opportunity to take a fantastic course on Pluralsight called "Domain-Driven Design Fundamentals" by Steve Smith and Julie Lerman.

Course

This course covers various concepts of DDD based on Eric Evan's book, "Domain-Driven Design - Tackling the Complexity in the Heart of Software," which I read many years ago.

Throughout my 20-year consulting career, I have only come across one company that implemented DDD modeling. This company specializes in managing pensions for a specific professional category. Enterprise applications like ERPs and Pension Plans require better design and architecture to minimize issues when scaling the model and implementing additional business logic.

While taking the course, I couldn't help but think about the two portals I developed for my client and the potential benefits of incorporating a DDD model and integrating business rules into the model.

In my next article, I will discuss a few key points that can be derived from the DDD pattern and explore how applications can benefit from its implementation.