12

Let's take some blogging application. User in this application has email, password. When a new user is registered, he should activate his account (for example, via email). But... is account activation, password, password reset tokens, etc, are domain concepts?

So I'm thinking to divide User concept into 2 parts: Account and Member. An Account is non-domain concept, it will handle activation, password reset, etc. But Member is domain concept, a member does not anything about passwords, activation, etc.

An Account will have reference to a Member.

What do you think about this approach? or may User be a part of domain?

Improve this question
13

Account and Member are two representations of users in different contexts.

The point of Domain-Driven Design is that we clearly state the problem domain or bounded context of each (sub-)system. We can then develop separate models for each context. The same concept like “User” may be represented differently in different models: “Account” for the authentication system, and “Member” for the blogging system.

The account management is not part of your main problem domain, that is correct. However, you will likely have or use another system or a subsysten for account management. The problem domain of that system does include account management.

Some concepts in different bounded concepts overlap, or represent the same entity. You will have to translate your concepts when you cross a context boundary – it is not a good idea to reuse parts of the model across contexts.

Improve this answer
5
  • thank your for an answer, very helpful. But how would you account with a member? I'm new in DDD, have read many articles, there are so many opinions on the same problems, and I'm confused with all these DDD things, can you give me a more concrete example how it should be implemented?
    – Teimuraz
    Dec 13 '16 at 13:03
  • 3
    @moreo Let's say every user has an ID. We can fetch an Account like accountManager.tryLogin(user,passwd) or accountManager.createAccount(…). Then account.changePassword(…), account.activate(…) are operations in the account context. In the blog context, we have a Member with member.getPosts() or member.getUsername() operations. When a user logs in (account context), how do we get the corresponding Member (blog context) so that they can write a post? Something like members.getMemberForId(account.memberId) allows us to cross the context boundary without mixing the different models.
    – amon
    Dec 13 '16 at 15:25
  • So the gist here is that even if it doesn't relate to the business domain, it is still a domain and should reside in it's own context? For instance, UI customization and preferences on a Web App that are persisted to a database. Those have nothing to do with the business domain, but are still a valid domain and should be represented as such?
    – Douglas Gaskell
    Jul 18 '19 at 20:35
  • @DouglasGaskell Yes. Any concept is a domain concept, the question is just which domain or bounded context.
    – amon
    Jul 19 '19 at 7:21
  • Great answer @amon. I think the last part of the answer should be highlighted! Just because there are similar concepts in different domains, does not mean they should be imported/reused. Domains, by design, should evolve independently of each other. If they start to depend on one another, its a failed DDD implementation.
    – alaboudi
    Feb 23 '20 at 17:37
5

If you are modeling domains you should stay away from commonplaces. User is such a commonplace. It's actually all and nothing. Be concrete and call it Blogger. That will immediately make it a domain concept.

Improve this answer
2
  • User may be a blogger or not in the same system. It may take different roles in the main domain.
    – PavelS
    Aug 16 '20 at 7:12
  • @PavelS You're talking about a person. A person can always have any number of roles (so being different actors).
    – user188153
    Aug 16 '20 at 7:56
3

But... is account activation, password, password reset tokens, etc, are domain concepts?

Why wouldn't they be? Users (Bloggers, Guests, Commenters etc.) have to get into the system somehow. If the domain doesn't address these business rules then who is going to?

You are right to separate Account and Member into separate entities. But I would invert the dependency. An Account is just a username and a password (and probably a salt and some audit info). It shouldn't know anything about membership. You can have an account without being a member, but you can't be a member without having an account. Member can also have a Profile, which can be of multiple types: Blogger, Guest etc.

Improve this answer
4
  • 1
    So are you suggesting to make Account part of a domain? Then, authentication / authorization also should be part of a domain?
    – Teimuraz
    Dec 13 '16 at 12:12
  • 2
    @moreo Yes, you can't talk about members without accounts and you can't talk about accounts without specifying how they got there or where they come from.
    – devnull
    Dec 13 '16 at 12:14
  • So which one would be the root aggregate? Can a member have multiple accounts?
    – Pepster
    Nov 8 '17 at 10:22
  • 2
    I agree with the answer, but there are applications that allow to have Members without an Account. Imagine a web shop with a backoffice that allows to enter phone orders. You'll have to create a Customer record, but that Customer might never sign in, therefore it won't have an account, where online Customers will have an Account.
    – Francesc Castells
    May 16 '19 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.