0

I am trying to understand DDD, but the scope to which we should seperate out domains seems a bit tricky to me.

Consider a few cases:

1. Utility

Consider I have a utility domain, with 2 helper function.

  • GenerateUUID
  • ValidateRegex

Should I split these two into utility/uuid and utility/regex domain as well?

2. Versioning

Lets say I have the first version implementation of GenerateUUID. Now, it is quite possible that there will be a V2, V3 etc, with potentially breaking changes. Should I extract them into seperate domains as well, like utility/uuid/v1 etc, which share the common functionality via utility/uuid/common?

Database Models

Consider I have the following tables in my database(assume relational):

  • Users
  • Preferences

Now, consider I have two operations, GetUsersWithAParticularPreference, and GetPreferencesForParticularUser.

Should I split these into seperate domains as well, GetUsersWithAParticularPreference in models/users and GetPreferencesForParticularUser in models/users/preferences, irrespective of what database/tables they access?

If I'm going wrong somewhere in understanding DDD too, please guide me.

Edit:

P.S. I understand that the cases I have posted above might be a bit too basic. However, I am trying to get my basics right, and set some guidelines, upon which to build a foundation.

Ayush Gupta
  • 101

2 Answers2

7

I think you may be starting off on the wrong foot with DDD. It's really crucial that you get a handle on what a 'domain' is in order to use this kind of approach. The examples that you are giving here are primarily technical. The closest thing you have here to a domain is the User but that's a pretty shaky place to start. In order to learn this, you should really focus on a true business domain.

So to start, forget about what you've got here. Set aside writing code for a moment. You first need to identify what your system is meant to accomplish. It sounds like maybe you don't have anything in mind so pick something. There are some well-known standard practice use-cases: a pet store, a music inventory system, etc.

JimmyJames
  • 27,287
0

There are different aspects of DDD. The strategic and tactical. The strategic design is about splitting your business in to different bounded context to serve your business better. When splitting the contexts, one should have minimal dependency on the other.

So splitting the solution into different contexts need to done with business knowledge.

DDD is to solve complex business problems. The problem you are solving is to not a complex business problem and DDD will be an over kill.

Nachiappan Kumarappan
  • 1,434
  • Yes, but I starting a project, so I am trying lay down some ground rules, trying to get the basics right, upon which to build the foundation – Ayush Gupta Oct 17 '19 at 16:05
  • 1
    There are different aspects of DDD. The strategic and tactical. The strategic design is about splitting your business in to different bounded context to serve your business better. When splitting the contexts, one should have minimal dependency on the other. So splitting the solution into different contexts need to done with business knowledge. So this might not be the best place to ask the question – Nachiappan Kumarappan Oct 17 '19 at 16:12
  • 2
    Except for your last sentence, your comment is actually better than your answer. – Robert Harvey Oct 17 '19 at 16:33