I am curious how you would approach it.
Imagine that you operate in the domain of Bikes selling. After workshops with the domain experts, you identified several subdomains (coarse-grained):
At the next workshop (fine-grained) you spotted that there is a further split to the next subdomains (the example is based on offers but it is the same for other coarse-grained subdomains):
So, there is a possibility to subscribe to new offers (or categories of offers) as a customer, there are discounts that can be applied to all offers (e.g. black Friday) or to a specific offer, and publishing of an offer (including approval) that is handled by 2 employees - author and approver.
Now it is time to categorize selected subdomains to:
- Core
- Supportive
- Generic
After categorization, you found out that there is 1 core domain and 2 supportive ones:
- Subscriptions - your company is known in the market as the one that has the greatest approach to handling subscriptions to offers. Your algorithm rocks the market and no one is able to do a similar thing. You spotted a Core domain.
- Publishing - you were not able to find any existing solution to tackle it and decided to handle it on your own. There is almost no business logic but the data structures are quite complex. You spotted a Supportive domain.
- Discounts - same story as with publishing, however here the data structures are simple. You spotted a Supportive domain.
With division in hand, you set about determining bounded contexts. It turns out that all 3 subdomains operate on the same objects, operate close to each other, and use the same (ubiquitous) language. You decide to wrap it to a bounded context called "Offering".
It is time to choose patterns for your subdomains:
- Subscriptions - complex business logic, complex data structures. You decided to go with the Domain Model pattern.
- Publishing - trivial business logic, complex data structures. You decided to go with the Active Record pattern.
- Discounts - trivial/no business logic, simple data structures. You decided to go with the Transaction script pattern.
After all, you decided to go with Modular monolith. The example structure could look like the below:
- Solution folder for each bounded context, e.g. Offering
- Inside each bounded context, a folder for each subdomain, e.g. Subscriptions, Publishing, Discounts
- Inside each subdomain folder, a set of projects (for Subscriptions: Application, Domain, Infrastructure; for Publishing: Presentation, Service, Business logic, Data access; for Discounts: Presentation, Business logic, Data access)
Then it could have been very easy to extract a subdomain (in case it is really needed) to a microservice. I omitted things like integration events etc. to distill the core of the problem.
How would you structure your solution based on the above assumptions?