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

A very late reaction, but maybe it still helps.

We are refactoring a huge legacy system in a team with 10 developers and are wrestling with similar problems. We find that creating duplicate entities for persistence is not such big problem perse, but once you start duplicating business logic (validations, etc) then things get messy quickly and conflict with the DRY principle. We currently are experimenting with repositories that communicate with other BCs, but find this only solves part of the problem (e.g. validation works, but only late) and you may end up with hidden RCP calls and that may cause performance problems. The other approach we are checking out is to separate out a common model after all, but this model not used directly; the entities in the BCs can extend the common models. You then have to decide if a certain piece of code/annotation is something specific for the BC or shared across all. Not sure where that will lead.

Regards, Tom



On 8-10-2014 17:32, [email protected] [domaindrivendesign] wrote:
>
> Hi all,
>
>
> For the last year, I've been part of a small team of 2 developers working on a large project that is usually tackled by much larger teams. We are trying to drive the design of our domain model using DDD principles. We are succeeding to a certain extent, but we are struggling with the definition and separation of bounded contexts. I would like to request your advice on this problem.
>
>
> To sum up the purpose of our application, we could say that it allows organizations to plan, track and report on collaborative projects. The main features are as follows:
>
>   * user management
>   * organization management (internal org chart, employees)
>   * relationship management (customer / vendor accounts, contacts)
>   * ratecard management (ser vices, pricing models)
>   * budgeting
>   * project tracking (task assignment, progress and completion, etc.)
>   * procurement (requests for proposal, business proposals, purchase orders)
>   * accounting (invoices, receivables and payables, payments, collection, etc.)
>   * reporting (budgeted vs invoiced, employee productivity, profit margins, etc.)
>
> There is a strong requirement for traceability between entities throughout the process: one should be able to reconstitute the path from an original budgeted line item up to an invoiced line item, thereby allowing an organization to produce high-quality reports.
>
>
> Reading the literature (both the Evans an d Vernon books), I gather that bounded contexts serve multiple purposes: defining a linguistic barrier within which concepts are clear and unambiguous, allowing teams to work in parallel with minimal friction, and reducing coupling between different parts of the model. I also gather that an application may be divided in bounded contexts of varying granularity, ranging from a single coarse bounded context for the whole application down to several fine bounded contexts, one per feature. Given the application we're working on, and the current size of our team, it's unclear where in that granularity spectrum we should be standing.
>
>
> There is a case to be made for having a single bounded context:
>
>   * Our team is small, we communicate easily and we have a low integration cost.
>   * We have elaborated a clear vocabulary within which concepts are clear(ish) and a mbiguities are few and far between.
>   * Integration between features is a selling point for this application, and so some entities are to be used by several features (e.g. a ratecard element can be used in a budget, a project timesheet and an invoice)
>   * No duplication. An organization is an organization is an organization.
>
> There is also a case to be made for having several bounded contexts:
>
>   * Although our team is small today, we hope to grow in the future. Both communication and integration will become harder. Bounded contexts would help us grow more easily.
>   * The application will assuredly grow, and so will our vocabulary. Ambiguities and polysemes will surely appear. Bounded contexts would help us better contain and demarcate models.
>   * Already, some concepts are used differently depending on the feature they live in.
>       o For example: a ratecard element is used as an entity within the ratecard management feature (allowing for change tracking and an approval process), but it is used as a value in other consuming features (where it is considered to be stable, valid and approved).
>       o Another example: an organization is responsible for hiring an employee within the organization management feature, while it is responsible for launching a project in the project tracking feature. Having separate implementations of the organization concept would allow for classes with clearer responsibilities (instead of having a God-like organization responsible for creating everything).
>   * Already, cha nges to a central concept (customer / vendor account) has rippled throughout the model because of the high coupling to it.
>
> As an experiment, we have attempted to separate the application in a few contexts. We saw some advantages: lower coupling between features and clearer responsibilities for classes. But we also saw some drawbacks: *lots* of duplicated code (n implementations of Organization, n implementations of Customer, etc.) and *lots* of translation code between contexts, which leads us to questions such as "why didn't I just use the original entity instead?" It also brought some questions regarding the visibility of concepts, such as "when defining the vendors to invite to a RFP, should I consult the relationship management context or the procurement context? and so will I need to add similar API endpoints to retrieve vendors in every consuming context?"
>
>
> N eedless to say, these questions are driving us mad and leading to discussions that, while interesting, ultimately leave us feeling like a) we don't understand anything, and b) we're losing our time on over-architecture.
>
>
> So... if you're not exhausted from reading this, what advice could you give its very confused author? :)
>
>
> Thank you very much in advance!
>
>
>