2

I have a project in which I have to manage projects, invoices and orders to providers. So I think that I can define three bounded context.

First bounded context: Projects. Second bounded context: Invoices. Third bounded context: Orders to providers.

Well, my doubt is how to the invoices of a project, because they are different bounded contexts.

I think that a project shouldn't have a reference to the ID of the invoice aggregate root, because really the invoce it is not needed for the logic of the projects, just to know the relation between them. But I am not sure if this is correct and I could have this relation.

But if this solution is correct, then to know to which project an invoice belongs to, should I have a reference to the ID of the project? Because really for me a project is not more important than invoice so I am not sure if it correct to say an invoce is part of the project.

Or perhaps another solution it would be to define an entity invoices (or value object) in the project bounded context to stablish the relationship and an entity or value object Project in the bounded context of invoices.

Or perhaps did I define incorrectly my bounded context?

Perhaps it is a bit generic question, but the main point it how to stablish the relation between two aggregate roots from different bounded conetxts, of perhaps, in this case, it is a bad design.

Thanks so much.

Improve this question
4
  • 1
    What makes you think that projects, invoices, and orders are separate bounded contexts? If there is logic spanning those entities, they belong to the same bounded context.
    – Greg Burghardt
    Sep 27, 2022 at 12:47
  • Perhaps in projects it is more hard to say, but for order and invoices, I can manage them in a isolated way, I don't need really invoices to can manage orders and at contrary. They are related, but one deoesn't need each other to can be manage. They are only related. But perhaps, I am wrong thinking in the way to definying the contexts.
    – Álvaro García
    Sep 27, 2022 at 14:00
  • 1
    @ÁlvaroGarcía I find it useful to think about the structure of the business and how different teams diverge in their ways of working. For example, are the people working with orders under the same management as those working with invoices? or is the business split into different departments under different management regimes with divergent rules and ways of working? Typically the overall management structure of a business is a key source of business rules and complexity so I think it often it helps to drive the structure of the domain model based on the structure of the business itself.
    – Ben Cottrell
    Sep 28, 2022 at 7:46
  • 1
    That also means the size and complexity of the business would be a key driver (including any external suppliers/outsourcing/etc.) -- if you're dealing with a small, self-contained business with <100 employees then the size of the business itself would usually be a limiting factor in terms of complexity since it'd be very unlikely that you'd get much or any divergence between ways of working around orders vs invoices - i.e. it probably has a very lean and lightweight management structure, and the small business would probably be more efficient if everything was unified.
    – Ben Cottrell
    Sep 28, 2022 at 7:57

1 Answer 1

Reset to default
3

You wrote:

I think that a project shouldn't have a reference to the ID of the invoice aggregate root, because really the invoce it is not needed for the logic of the projects, just to know the relation between them.

That is a perfectly valid point of view which also fits to the normal life time of these objects:

  • First, someone defines some project containing a list of services. Those services are constituting the project, so they could be part of the projects's bounding context.

  • Assumed this is a paid project, the service provider will create one or more offers for those services. Depending on the size of the business, these offers may require a formal ID, or they could have just a date and description in text forms about the services offered.

  • Next, a customer creates some order for the offered services. That order will usually get an ID under which the account staff can store and find it. It will also have a relationship to the former offer - maybe it's ID, maybe given in text form (but if it is just in text form, someone from the service provider will have to associate the order with the service or project somehow - at the granularity the specific business requires).

  • Later, after the services are delivered, an invoice is generated, referring to the former order.

That is usually what happens in several service oriented businesses, so there is this chain

Project - Services - Offer - Order - Invoice

with the project at the very beginning and the invoice at the far end.

From this, the project belonging to an invoice can usually be recreated if necessary. However, which of those relationships you really store in your system in a form which can be evaluated efficiently not just by a human, but also by a software, is a different question! It does not depend on which kind of relationships exist in theory, but which kind of processing the system shall be able to do.

But I am not sure if this is correct and I could have this relation.

It is not wrong, but not the only valid solution. What you need to analyse is the kind of use cases / processes / functions you want to implement in software. If you have mostly use cases which run on projects/services, and others for invoices only requiring some project ID, but not functions from the project's bounded context, then it makes most sense to give each their own BC.

But if this solution is correct, then to know to which project an invoice belongs to, should I have a reference to the ID of the project?

As I said, if you store such IDs, is totally dependend on the processes you want to implement.

For example, you want to provide a use case like this: "Finding out if there are there any unpaid invoices for one specific project". If you don't want someone having to use a global text search to identify the potential invoices for a specific project afterwards (and look manually through some scanned PDF files afterwards), it may be a good idea to store the invoice together with some information where it belongs to whenever it is created. If you store the project ID inside the invoice, or a project ID together with a service number, or just an order number (whilst the order is related to the project somehow) is up to you and maybe also influenced by the way how and by whom these information and references will be entered into your system.

So in short: you cannot answer these kinds of question just by looking at the data. You need to think of the processes you want the system to support, the behaviour of the system, which relationships must be expressed in machine-readable form and which ones can stay there loosely, in a non-strictly defined manner. Also numbers matter: if your business produces one invoice per year per customer for a service which is the whole project, you will have different requirements than when your business produces 500 different invoices per year per customer for 50 different projects, where each project consists of a dozen different services.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.