How to define contexts and figure out which stuff belongs in which

[BitPhinix]

Hi katzien,
First of all: Great talk!

But it left me with a lot of questions: I'm unsure how you would go about defining contexts. Let's say for example you have an app where you can create accounts, add contacts and share documents between them.

In your example you have an adding context, would I put the "adding" of new accounts, contacts and documents inside a common "adding" context (Which would be grouping by functionality again) or would I go and create a "register", a "addcontact" and a "createdocument" context? And if so, would I create a different context for updating e.g. the accounts and documents? If that would be the case wouldn't that mean that I would have to duplicate a lot of the validation logic?

I'm really unsure how to figure out what contexts there are in an application and how to figure out which stuff belongs in which.

Regards

BitPhinix

[katzien]

Hey @BitPhinix!

Thanks for the kind words, and sorry for the delayed response!

So first things first, the "adding" in my example is a service, not a context. Context is a higher level concept, in the case of my app there's only one.

I think that might be where your confusion comes from? Sounds to me like your app has at least one "primary" context, which is a "user sharing files" (or a "file sharing service"). So in that case, you'd have services like "create an account", "add contact", "share document".

As for

would I go and create a "register", a "addcontact" and a "createdocument" context? And if so, would I create a different context for updating e.g. the accounts and documents?

I would probably go with "account", "contacts" and "documents" as the three distinct areas in your domain? Then you can implement the functionality (adding, updating) in each of those files? I'd probably just have those three as files unless they get too big, then you can maybe turn them into packages with multiple files in each (for the service, model etc)?

An alternative would be to try and name the packages after the service they provide, so something like "account-management", "contact-management" and "document-sharing", or maybe even just two top level ones: "registering"/"account" and "sharing"? In the last case the contact management would be pulled into the document sharing, but if you can add contacts in your app regardless of sharing (ie. those two are not tightly coupled) then that's probably a bad idea. Overall in this case the service names are way longer than names after the entities ("account", "contacts" and "documents"), so I think I'd go with the entity names. And start out with those three as files rather than packages for simplicity. It also lets you put adding / updating / deleting all under one umbrella.

Hope this helps a little?
:)

[BitPhinix]

Thanks a lot! That really cleared things up for me. Since I wrote the issue I did a lot more of digging into the topic and came to nearly the same structure as you mentioned above. That's really reassuring :)