Hi everyone,

I was wondering if, are there any documentation or existing examples regarding isolating a domain via a domain api, i.e. providing a query interface?

Reference(32:28):

[ODC 2018] Domains and Services Architecture


Specifically:

  • For a single Entity, am I to copy/mimic the database entities to be exposed and expose this copy with the desired depth(n-depth relationships)? If this is the case, should plain structures be used? Plus, will a specific service be implemented per need? (GetById, GetByName, GetByAddress, etc)?
  • For a List, the same questions above apply, but are these to be more "screen ready"? Kind of a presentation layer serving "ready-to-use" aggregates built thinking of the screen usage?


Thanks! 

Nuno 

Solution

Hi Nuno,

The idea of the query model is for a domain to provide public entities that can be leveraged by other consumer domains to search or list data and even join with their own data, without exposing the entire internal DB model of the service (which is the query and the command model together). Since OutSystems 11, references to entities are managed as weak references, making it suitable to provide the query model as part of the light API that a service provides to other domains.

In simple cases, the query model and the command model can be the same, if there is no complex or sensitive information to be hidden to external consumers. Normally the query model only exposes data required to search or list, and then details are retrieved through some Service Action.

The query and command models can simply complement each other, to avoid having to sync data: E.g., you can have an Entity Customer in the exposed query model with the public fields used to search or list customers, and have an Entity Customer_Detail in the command model that share the same Id and add extra sensitive or control fields (e.g. CurrentBalance, PriorityScore).

Alternatively, in more complex situations, or if you already have a data model that was not prepared with this pattern, the query model can be a Hot Cache with data prepared for the common use case of searching and listing records

Solution

"(...)references to entities are managed as weak references(...)" - I see! This unties a knot in my head.

"(...)only exposes data required to search or list, and then details are retrieved through some Service Action." - this fit perfectly.


I wasn't expecting the speaker to answer directly. pretty awesome :D

Thanks again!


Nuno