CODEWITHSUNDEEP
domain-driven-design
Leandro De Mello Fagundes
Leandro De Mello Fagundes

Reputation: 50

Where "global entities" should be in a DDD SaaS example?

I'm trying to understand the DDD better. Eric Evans's book is thought, but I'll give my best to understand it.

As I understood, the Domain is my main problem. For example, I have a SaaS specific for Car Stores. If you have a Car Store, you can use my system where you can input the cars you have, and photos, details, prices. People can see the car over the internet using a public portal, but your team have the right permissions to input the date, update it, sell the car, manage your finances, anything else you need for an excellent experience with our software.

My team has to keep who is the manager of the store, give him the right permissions, and for support reasons, must have a portal where can do this kinda stuff.

So, we have 3 systems:

  1. The public portal for the customers of the Car Shop see the cars they have
  2. the System for Car Shop employee and manager, and;
  3. System Support Portal, for my team to activate new Car Shops ou shut down if they don't pay us.

For this case, do I have 3 domains, or Selling Cars is my Domain with subdomains? The User Entity is everywhere in the system because if you are joining just to see the car, or manage a Car Shop or manage my product, you should be a user.

I'm trying to design what they tell in the books but I'm completely confused about how to start it. I bought the Vaughn Vernon book, and in the second chapter, I got myself the same questions.

Thanks in advance for any help.

Upvotes: 0

Views: 224

Answers (1)

Francesc Castells
Francesc Castells

Reputation: 2857

This is a very broad question, but regarding the systems and domains, I'd say that your domain is something like "Online cars marketplace". This is your problem space, it's where the "business knowledge" applies and it doesn't say anything about how your solution is structured and implemented.

The public portal (possibly with web, iOS and Android versions), Car Dealership Management portal and backoffice that you mention are Front End applications, but they are not really subdomains. Each FE application will be an interface to more than one subdomains. For example, the Sellers Portal will have something like "Car Ads Management", "Orders", "Customers Management", etc. and the Public Portal will be able to see the Ads created by the Dealers, place Orders and become customers of the Dealers. So, the same subdomains will have UIs in both FE applications.

Regarding the "How to start", I would say you could try to create a context map for your system. Maybe do the following:

  1. Create mockups of the screens and functionality you envision for each of your FE applications. This will include things like, register Dealership, place Ad, remove Ad, search ads, contact dealer, etc.
  2. Try to find the bounded contexts by grouping operations and data together. For example, you'll create and edit ads and also search and view ads which you can put together in a BC. Then other operations like Register dealership and disable dealership can go together in another BC. And so on.

Note that this is probably the most difficult part of DDD and there isn't a single answer. This is is just an idea of how you can look at solving this problem. There are techniques like Big Picture Event Storming (see this article as a sample, but there is more information online) that help solve this problem.

Upvotes: 1

Related Questions