Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>entities below the aggregate root should be immutable.</p> </blockquote> <p>No. Value objects are supposed to be immutable. <strong>Entities can change</strong> their state. </p> <p>Just need to make sure You do proper encapsulation: </p> <ul> <li>entities modifies themselves </li> <li>entities are modified through aggregate root only </li> </ul> <blockquote> <p>but Policy.addAuto() won't quite fly because one can't just pass in a new Auto (right!?)</p> </blockquote> <p>Usually it's supposed to be so. Problem is that auto creation task might become way too large. If You are lucky and, knowing that <strong>entities can be modified</strong>, are able to divide smoothly it into smaller tasks like <code>SpecifyEngine</code>, problem is resolved.</p> <hr> <p>However, "real world" does not work that way and I feel Your pain.</p> <p>I got case when user uploads 18 excel sheets long crap load of data (with additional fancy rule - it should be "imported" whatever how invalid data are (as I say - that's like saying true==false)). This upload process is considered as one atomic operation.</p> <p>What I do in this case... </p> <p>First of all - I have excel document object model, mappings (e.g. Customer.Name==1st sheet, "C24") and readers that fill DOM. Those things live in infrastructure far far away.</p> <p>Next thing - entity and value objects in my domain that looks similar to DOM dto`s, but only projection that I'm interested in, with proper data types and according validation. + I Have 1:1 association in my domain model that isolates dirty mess out (luckily enough, it kind a fits with ubiquitous language).</p> <p>Armed with that - there's still one tricky part left - mapping between excel DOM dtos to domain objects. This is where I sacrifice encapsulation - I construct entity with its value objects from outside. My thought process is kind a simple - this overexposed entity can't be persisted anyway and validness still can be forced (through constructors). It lives underneath aggregate root.</p> <p>Basically - this is the part where You can't runaway from CRUDyness.<br> Sometimes application is just editing bunch of data.</p> <p>P.s. I'm not sure that I'm doing right thing. It's likely I've missed something important on this issue. Hopefully there will be some insight from other answerers.</p>
    singulars
    1. This table or related slice is empty.
    1. POPlease clarify how create/update happens against child entities of an aggregate root
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USArnis Lapsa
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for the answer.
      singulars
      1. PO
      1. USchristian
    2. CORegarding the immutability of entities, I meant from the OUTSIDE, so we're on the same page there. I see that the atomicity can be broken down and that may get one somewhere, but if that can't happen (like your example, but even in my policy example), looks like the suggestion is complex factories...which end up echoing all your domain's modifiable state or have to map from DTO-type things. Maybe others will shed some additional light.
      singulars
      1. PO
      1. USchristian
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload