TLDR: not quite sure whether I got my Bounded Context right.


I have a domain model in one Bounded Context:

Domain Core

Entire model is in the same bounded context. Bounded context has two responsibilities:

  • administering products/rules/parameters
  • parsing/executing products' rules

Business invariants pertaining to administering products, rules and parameters are contained within the aggregates themselves. The existing Product/Rule/Parameter model is very suitable for this.


Problems arise when executing rules. In order to execute a (set of) rules, I need to fiddle around a lot, query and filter across multiple collections:

  • A specific Product
  • All of the Rules belonging to that Product
  • All of the Parameters belonging to those Rules.
  • Sometimes I even need to filter across those collections for very specific combinations and this is getting more and more cumbersome.

So I created a new class ExecutionProduct as a placeholder for all the filtered data needed by the ExecutionRule + started adding filtering logic to ExecutionProduct. It is not a perfect fit for the execution model + there is a lot extraneous data within the aggregates, but I can manage.


ExecutionProduct got me thinking whether I should move parsing/executing responsibilities into a standalone Bounded Context, since that would allow me to morph existing data into more suitable format for execution. Please note that when executing rules, there is no need to persist anything: it consist of running through all the rules and doing complicated filtering, comparison and other business logic.

  • 1
    What is your domain? It's a bit unclear from your examples. The level of abstraction you are working with does not seem very useful unless you are actually in the business of creating rules engine software. What I mean is, by separating rules, parameters, and the data they act upon, you are essentially creating a CRUD system inside of a DDD system. So unless your domain it is truly creating such a system, I would suggest trying to make this system more concrete. – king-side-slide Oct 5 '18 at 15:13
  • Yes, I am creating a business rule system. The part with the Product, Rule and Parameter is the core of the system. – robotron Oct 5 '18 at 15:20
  • @king-side-slide: Which part would you consider CRUD? Administration or execution? – robotron Oct 5 '18 at 16:17
  • 1
    The purpose of DDD is to combine business rules with the data they act on. Doing so in a way that properly modularizes the behavior of a system is a far-from-trivial exercise in modeling, but results in a powerful abstraction of it's functional requirements. A procedural (CRUD) approach generally takes the form of: Command -> Query -> (data) -> Validation -> Mutation -> Persistence. DDD transforms the above into: Command -> Query -> (domain) -> Mutation -> Validation -> Persistence. By asking telling your data (domain) to mutate itself, you can be assured... – king-side-slide Oct 5 '18 at 18:36
  • ... that two mutations of the same state undergo the same validation. This is not so with CRUD (without discipline), because validation is not hard-coded to mutation in the same way. Essentially, your "objects" are just bags of data being passed around, inspected, and validated according to some command context. Your system represents the same thing. Products are passed to Rules with Parameters for validation. Because a Product is unable to validate itself, business rules are a result of configuration. – king-side-slide Oct 5 '18 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.