13

I have a question regarding Domain Driven Design. In the User Account/Profile bounded context of my application, there is a User Entity with account information(id, username, password, email, salt, etc) and profile information(fullname, avatar, birthday, gender, etc). I also have another bounded context for Job Positions/Applications, in which each Job Position has an Employer User and each Job Application has an Applicant User.

The question is, should the Employer/Applicant User in Job bounded context be the same User Entity I use for user account bounded context? Or should I design different User type entities for Employer and Applicant?

As you see, only information such as id, fullname, email and avatar from the account bounded context is relevant in the job bounded context. If the Employer/Applicant is the same User Entity from Account/User Profile, it will load a lot more useless data(dont need to know user password for an employer/applicant). But if I create different entity classes for them, it will make data persistence more tricky as changes made in different entities classes can change the same data in the same database table.

What do you think? Should I use one User Entity for all, or different User Entities for different bounded contexts/aggregates? If the latter is desirable, how can I do with data/entity persistence?

Lord Yggdrasill
  • 3,197
  • 4
  • 26
  • 42
  • Your bounded contexts share the same DB? Ideally they shouldn't. If they do then you need to make it clear which BC owns which piece of data and only allow the owning BC to change that data. – plalx Mar 23 '17 at 19:23
  • 1
    I dont understand what you are saying. Its the same application, just different bounded contexts. I always use the same DB unless its a different application. – Lord Yggdrasill Mar 23 '17 at 20:06
  • 1
    BCs usually are deployed as micro-services and have their own DB. – plalx Mar 24 '17 at 00:40
  • 3
    I am sorry I read two books of DDD and many articles on the Web regarding DDD, none of them said bounded contexts must have their own databases. I would need some citations for your claim. – Lord Yggdrasill Mar 24 '17 at 03:05
  • 2
    Thre are plenty of sources. [Source 1](https://www.infoq.com/news/2014/11/sharing-data-bounded-contexts), [Source 2](https://msdn.microsoft.com/en-us/magazine/dn802601.aspx). Just lookup Bounded Context integration. It's very rare that the integration is made through a shared DB. – plalx Mar 24 '17 at 14:01
  • Why do you think creating another entity class would complicate persistence? These would be completely different classes, having different tables/documents, possibly connected only by user id. Besides that, as @plalx noted, bounded contexts can use very different persistence technologies. In fact, they can be different modules or even totally different applications. From what I understand - profile/job bounded contexts serve different purposes and are almost totally disjoint (only the user id is a common part). – Mike Wojtyna Mar 30 '17 at 20:19

1 Answers1

14

It is old question and you probably solved this dilema somehow, but I will try to answer it.

You wrote:

"only information such as id, fullname, email and avatar from the account bounded context is relevant in the job bounded context"

Are they really relevant to Job BC? With Entities (and even more: with Aggregates) you are modelling processes, not data. In which process or use case of Job BC do you need fullname? Is there a requirement in the domain that persons with specific first or last name shouldn't be employed? I assume not. By saying so you probably had in mind, that you had had to display some screens where fullname of a person had been displayed. But screens are not processes, they are just reports. You shouldn't drive your model by reports/screens/UI, but by processes that exist in specific domain.

Ok, but how to do that? Obviously you still need to generate some reports/screens. Don't you? The answer is: you need CQRS (https://martinfowler.com/bliki/CQRS.html). Command stack is just your model of processes reached by Aggregates etc. So your building blocks will be persisted by some ORM. And data model for them will be driven by how they (the building blocks) look like. Use some ORM here that can easily persist even complex Aggregate, for example Hibernate.

Then you have to build up Query stack. I see two ways to achieve it and they depend if you have both BC in the same DB schema or not.

When both BCs are on the same schema, just use some database views that will construct data for your reports/screens. Use some really fast and flexible for complex queries ORM here like MyBatis or Spring JDBC (or even plain JDBC if you like to struggle with JDBC anger ;) ). Don't use Hibernate here if you are not forced to, because you will find that it is good to be as close to SQL as possible in this stack. Data query abstractions will force you to struggle with used framework/ORM to achieve complex joins of data model that is driven by Aggregates and theirs processes, not screens. Another reason is that in ordinary business application there are several orders of magnitude more readings than writes to DB, speaking in CQRS, there are more Query stack usages than Command stack usages, so you need something fast here.

When BCs are on different schemas you need to build the Reporting Database (https://martinfowler.com/bliki/ReportingDatabase.html) which will "merge" both schemas. Then you can do views on merged schema and the problem simplifies to above one.

Please notice that Reporting Database gives you another scaling possibility: this database is read only, so it can be easily replicated among several servers, your Query stack services can be multiplied and hidden behind some Load Balancer.

Ok, but what with email address property? You probably have a use case in your domain that Employer or Applicant should be notified about some action/process done on domain. I think Domain Service (or Domain Event handler) handling this use case should ask other BC's service for email of this particular user (or broadcast Domain Event that will be handled somewhere). Or even better - it should delegate this work to some Notification Service in yet another BC. And this Notification Service will ask Account BC's service for email address.

In my opinion Bounded Context (along with Ubiquitous Language) is the most important idea of DDD. This is really powerful tool to avoid Big Ball of Mud during modelling. And it is really not easy to determine Bounded Context in real domains :)

krzys
  • 306
  • 2
  • 6
  • Would this mean that there is a "User entity" which has it's ID shared by the different BC's? – Pepster Nov 08 '17 at 11:17
  • 1
    @Pepster In general: yes (just to have data relationship feasible). In details: there shouldn't be User entity in Job BC. "User" means nothing in this BC. There are "Employee" and "Employer" maybe. And they can have ID of some "User" from Account BC. To have data matched. – krzys Nov 14 '17 at 20:19
  • 1
    How to trick my brain to think this way? :) :) Thank You for this answer. – Dzintars Sep 01 '19 at 13:53
  • Thank you for your comprehensive and complete explanation – Moradof Sep 07 '20 at 09:58
  • 1
    That means you have 2 "User entity" with same name in different Bounded Contexts. Although I think username and password should be in Authentication Bounded Context because just Authentication BC need them. – Moradof Sep 07 '20 at 10:01