1

The context, or bounded contexts, it could be defined as a logical boundary of a domain where particular terms and rules apply consistently.

There are another definitions but more or less, this could be a star point.

According to that. Supose that I want to manage the order of the clients. In this case I would have a bounded context Orders, for example, in which I have two entities, order and items. And order it would be the aggregate root. And order would have property for the ID of the product.

So I need another context, Products, to manage the product, with one entity, Products, that is the aggregate root, with the provider, the reference and the information of the product.

Supose now that I want to control the stock of the products. Is it a good idea to use the Products context, adding a new property StockQuantity to the Product entity? Or it would be better to create a new context that it would be Stock context?

If I create a new context, I would have only one entity, ProductStock, with one property for the ID of the product and another property for the quantity.

In general, my problem is how to define the bounded contexts.

The concept of context it is to have terms and rules that are coherence and unique in this context. If I have a concept that has different meaning in different use cases, then I should to use another context.

But for example, stock, from my point of view, I can be wrong, sure, is the same in the context of products than if I have a different context Stocks, it is the quantity of the product that I have in the warehouse.

Perhaps I am in some way mixing the concepts of term (what mean a concept in a context) with functionality (that I could define as what can I do with this term or concept). Perhaps the context of Products can have the functionality to manage the basic information (reference, provider, description...), the functionality to control the stock of the product (increment or decrement the quantity of stock) and another posible functionalities related with products.

Also in all this cases it seems that the aggregate root is the same, the product entity, which I can use the method IncreastStock() for example, or DecrementStock().

With orders, I need another context, in this case I see clear that is a different part of the application.

So for this basic example, how could I design the contexts for the case of products, orders and control of stock?

Thanks.

Improve this question
2
  • 1
    Boundaries if they exist at all, generally derive from the human and organisational structures which your users and stakeholders already occupy. For example, different teams and departments within a business each with different responsibilities and needs from the software, with different managers who have different priorities and perspectives on the business. For example, the sales manager probably cares about different things to the Warehouse manager, therefore implying natural boundaries which your domain would probably represent as separate bounded contexts.
    – Ben Cottrell
    Commented Jun 15, 2023 at 21:46
  • yes, so you don't have an "Orders" context, you have a "SalesDepartment" context where the Order class in that is different from the Order class in the "Warehouse" context
    – Ewan
    Commented Jun 16, 2023 at 17:40

0

Reset to default

Your Answer

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

Browse other questions tagged or ask your own question.