Re: Large domain, small team: how many contexts?

Hi all,
 

 Thanks for chiming in. @Rob I didn't know about DCI, I will do some research, thanks for the tip. @All I also realize that my ramblings were very general, I will try to ask specific questions to help me understand the usage of bounded contexts.
 

 Consider what we could call the procurement BC. During the course of a Project, an Organization may need to outsource some tasks. To do so, a Project Manager will first draft a Budget to plan what costs this will incur. Once the Budget is approved, a Procurement Manager will draft a RequestForProposal based on this Budget. It will then authorize some BusinessPartners to consult it and submit BusinessProposals.
 

 This requirement involves concepts originating from several contexts: User Management (the underlying Users that are acting as Project Manager and Procurement Manager), Organization Management (Organization), Business Relationship Management (BusinessPartner), Project Tracking (Project), Budgeting (Budget) and finally Procurement (RequestForProposal, BusinessProposal). In this case, it seems to me that the Procurement BC is a consumer of all these other BCs.
 

 1. When implementing the Procurement domain model and the orchestrating application service, should we implement Procurement-specific representations of all these entities? While it would make sense to implement these entities as values in the Procurement context, there are several concepts at hand and adding context-specific representations as well as the necessary translation services would increase significantly the size of the code base. Just to clarify, we are considering a single persistence source for every entity and so are not considering duplicating tables.
 

 2. (if the answer to the 1st question is affirmative) There are several other bounded contexts that consume the User, Organization, BusinessPartner and Project concepts. If we were to implement context-specific representations of all these concepts in all consuming contexts, we would end up with 10 Users, 10 Organizations, 10 BusinessPartners and 10 Project classes. Again, huge increase in code base size. Is it worth it?
 

 3. (if the answer to the 1st question is affirmative) The Procurement context UI must allow the end-user to select a source Budget, select BusinessPartners to authorize, etc. Considering that /budgets and /partners REST endpoints already exist in the Budget and Relationship Management contexts, should we add Procurement-specific endpoints for the Budget and BusinessPartner concepts, such as /procurement-budgets and /procurement-partners? Similarly, we would need to add /project-partners, /invoicing-partners endpoints as well?
 

 Surely there is something fundamental I'm not grasping here. I do see the advantages of decoupling these areas of the system, but the required cost to implement that seems prohibitively high. What am I missing?
 

 Once again thanks for reading and for your input!