StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>My answer does not cover the detailed implementation / code as it seems that you are using this as an exercise to learn more about DDD.</p> <p>Remember that in most cases you'll not be able to get the model right the first time and need to evolve the model. As you “play with it” certain rigid parts will become more flexible to change. (Like a gardening glove as per Eric's analogy). As you gain new insights into the domain, you'll find that you need to introduce new concepts into your model. Using “simple examples” has dangers for example they can lack depth. But simple examples are sometimes needed to get the hang of DDD and fortunately we can <strong>evolve the example</strong> too ;) </p> <p>One thing I've heard Eric Evans mention was that if the domain does not feel right or you have trouble expressing something in a model you might be <strong>missing a concept</strong>. Naturally if you have the concepts in your domain you can “get a feeling” or find a natural place where validation will occur.</p> <p>Having set the context I thus have a <strong>proposition</strong> as follow:</p> <p><a href="http://books.google.fr/books?id=NefmonGgEEMC&pg=PA267&hl=en&source=gbs_toc_r&cad=4#v=onepage&q&f=false" rel="nofollow">Enterprise Patterns and MDA</a> has some complex patterns but the idea you can take away is the <strong>CapacityManager</strong> of the <strong>Inventory archetype</strong> as guidance. Unfortunately the model on pg 278 is not available online but have a look at the ServiceInventory archetype.</p> <p>The instructors are selling their services to students. (Instructors get a salary last time I checked :). If I were to map your example to the Inventory archetype for ideas I would use:</p> <ul> <li>Inventory - List of instruments/courses</li> <li>ServiceType - Instrument / Course details, start end etc</li> <li>ServiceInventoryEntry - Instrument + places available (uses capacity manager)</li> <li>ServiceInstance - Enrollment - place in class (Scheduled, Booked, Canceled, Completed)</li> <li><strong>CapacityManager</strong> (used by ServiceInventoryEntry)</li> <li>ReservationRequest - Enrollment request</li> </ul> <p>I think the key concept added is the CapacityManager: You can call the ServiceInventoryEntry::getCourses() method which will use the CapacaityManager (service or class) to show you / calculate the available teachers or return the default one. Thus, call it multiple times depending on the context: Default or Propose a list of available places/seats/instructors.</p> <p>With this model you should be able to find natural place (where and when) to validate. The guidance from <a href="http://rads.stackoverflow.com/amzn/click/0130668397" rel="nofollow">Streamlined Object Modeling</a> is to put validation where the data is. Not to be taken as a hard rule but there is a natural tendency for objects to have the proper concerns and data grouped together. For example the capacity manager knows about enrollments and instruments. (From MDA - CapacityManger: Manages utilization of capacity by releasing ServiceInstances)</p> <p>To get your aggregates see what transactions / changes you'll do so that you can ensure they enforce the invariants (rules). In your example I would make ServiceType(Course) a value object, ServiceInventoryEntry and ReservationRequests aggregate roots. (Depends on how complex you want to take your rules). You can also add Students and Teachers as parties as per the MDA book. I tend to use repositories to get hold of my aggregates and then also rely on inversion of control as per Jimmy's book you referenced.</p> <p>The reason I like the MDA patterns is that it <em>makes me think of use cases and model concepts that I or the business would not have imagined</em>. But, be careful to <em>only model what you need</em> since the MDA patterns can be big and even enticing. The good thing is that they are designed to be modular or "down scalable".</p> <p>So in short: - Your aggregate roots should ensure your domain is in a valid state (Rules / Invariants) - Put the validation where the data is. Your model will guide your.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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