User management CRUD vs. generic domain

[aschrijver]

This is just a FYI of a consideration I am making currently about how to implement User Management.

The article series advises to go with straightforward CRUD to implement user management. This is certainly prudent if you know that you only need very basic user management features. In many ocassions I think the amount of these features start to warrant following a DDD approach too.

I wrote some of the features I need, and think I'll choose the latter approach:

User (generic domain)

Standard, not core to the service this subdomain has use cases for User stakeholders:

Ref.	Stakeholder	Use case and description
USR-01	Public	Register new user: To become a user a person must register their username, password and a valid email address. The username cannot be changed after registration.
USR-02	Public	Send email verification: After signing up the system sends an email notification with a link to confirm and verify the email.
USR-03	Public	Verify email address: Clicking the link in the email verification message triggers the verification on the server. If the verification succeeds, then this is recorded and the user is valid. Only with a verified email address the user is allowed access to the system.
USR-04	Public	Sign in user: To gain access to the center services a user signs in with a valid username and password.
USR-05	User	Sign out user: A user that is signed in can sign out at any time. This action will sign them out from all devices they were signed in with.
USR-06	User	Reset password: If the user forgot their password they can request a password reset and receive an email notification with a link to a password reset screen where they can set a new password. A successful reset allows them to subsequently log in with that password.
USR-07	User	View private profile: A user can view their own user profile which shows all the user details of the user including email address and other personal information.
USR-08	Public	View public profile: Anyone can view the public profile of another user, which displays a subset of the user details of that user's private profile.
USR-09	User	Edit user profile: A user can edit the user details of their private profile and save the changes. Only their username cannot be changed after registration. Changing the password is a separate use case.
USR-10	User	Change password: When signed in a user can change their password by typing the old password, followed by the new one twice to ensure it is typed correctly.
USR-11	User	Close user account: A user can terminate their own account . When doing this they are provided they are provided the option to have all their activities to be either removed or anonymized (depending on whether it is private or public data). Then their personal profile is deleted, after which the user is automatically signed out of the system.
USR-12	Public	Request authentication: When actions are requested that require authentication, then a redirection is made to the login and signup facility. After authentication is established the user is directed back to the page where the request was made.

This list is not yet even complete, e.g. I need 'Export user data' and 'Anonymize user content' for GDPR-compliance, and there are touchpoints to other subdomains, like Admin (with Auditing), Reporting (with Dashboard config), Notification (user-type differentiation), etc.

[aschrijver]

I just found The DDD Paradox with a useful insight:

DDD is a silver bullet [..] I need DDD strategic patterns to understand a domain deeply enough, to decide whether DDD tactical pattern are relevant, if any. Said another way: strategic patterns are useful to understand any domain, whereas tactical patterns may not be relevant to your context.

CQRS is definitely not a silver bullet, neither are Event Sourcing, Repositories, Entities or Value Object. But DDD in its strategic aspects (domain analysis, bounded context, etc) is pretty much useful all the time. [..]

This is the DDD paradox, DDD is an approach that even helps you determine when you don’t need it, which makes it pretty much universal.

[roblaszczak]

+100 on

DDD is a silver bullet [..] I need DDD strategic patterns to understand a domain deeply enough, to decide whether DDD tactical pattern are relevant, if any.

We didn't introduce strategic patterns at the beginning, because we believe that it's easier to start with tactical patterns. But strategic patterns are more important than tactical patterns 😉 The good news is that we are already working on the next parts of the series, where we are covering them!