Suppose I have an aggregate, Foo. This aggregate is represented by a simple flat table in the DB...
Foo
------------------------------
| id | prop1 | prop2 | prop3 |
| 1 | a | b | c |
| 2 | a | bb | cb |
| 3 | ac | bc | cc |
------------------------------
Now on the frontend I want to filter Foo. I have a form where the distinct properties of foo need to be displayed as a list and selected from. When a property is selected, I need to query Foo and find the subset of rows with the selected property. Then I need to select the distinct values for each property in the subset of rows selected by the search query.
For example, let's say the user picks a
as the value for prop1
...
SELECT DISTINCT * FROM Foo WHERE prop1 = 'a';
What's the appropriate way to model this in DDD? My first idea was to create a completely seperate aggregate for modeling the results of the above query or those like it...
class DistinctFooProperties
{
private $prop1;
private $prop2;
private $prop3;
public function __construct(
StringCollection $prop1,
StringCollection $prop2,
StringCollection $prop3
) {
$this->prop1 = $prop1;
$this->prop2 = $prop2;
$this->prop3 = $prop3;
}
public function getProp1Possiblities() {
return $this->prop1;
}
public function getProp2Possiblities() {
return $this->prop2;
}
public function getProp3Possiblities() {
return $this->prop3;
}
}
class DistinctFooPropertiesMySQLMapper
{
public function findBySearchObject(FooSearchjObject $fooSearch) {
// Search and return DistinctFooProperties
}
}
This leads to a bit of complexity. DistinctFooProperties
and FooSearchObject
are going to mirror the properties of the Foo
aggregate very closely, but far enough that I can't think of an interface to enforce that they all should be talking about the same properties.
Is there a standard way to approach this problem?