Skip to content

Episode 32 – Questionable Approach

2013 July 23
by Kerry Street
Share

Kerry and Rinat answer listener questions about code syntax, differences between event sourcing and relational storage, and concrete examples of Domain-Driven Design (DDD) concepts. Along the way, your questions lead them to questioning themselves and to consider an alternate approach.

Download (mp3): Episode 32 – Questionable Approach – (54 minutes)

Subscribe via RSS | Subscribe for free in iTunes

Episode References:

What do you think?

One Response Post a comment
  1. July 27, 2013

    Thanks for taking the time to answer my question. In general it has became clearer. I guess my biggest confusion from the very beginning is about Bounded Context. For example in the app I’m working on there’re several sub-domain, and each sub-domain has a word “item”. However in each sub-domain “item” has slightly different meaning: physical item I have on a shelf vs an item I have available to be sold online. So to me it seems each sub-domain is in separate BC. But at the same time a lot of other terms are shared through entire domain. For example item Code and SKU has universal meaning.

    So, how do we deal with documenting and modeling this? Describe shared language separate from each BC language? Have several layers of BCs (in Rinat’s example it would be American English vs British English)? What if sub-domain has to deal with two BCs, how do we model it? Is this a sign I need to re-model my sub-domain and probably break it apart? I try to avoid this situation and in general have one-to-one mapping of BC to sub-domain, but still things can happen.

    re design and application development: I’m still very much a beginner in DDD, but thought I’d share how we approach d&d in Agile Harbor, since it seems to work pretty well for us:
    1. I talk to domain expert and we choose which feature to work on next.
    2. I spend many-many hours with domain expert where he describes the feature, draws diagrams, and tables with what user does and how things change, step-by-step. Usually we uncover a lot of hidden scenarios and edge cases in this discussion. My goal at this point to become domain expert myself (or as close as I can get to one) and understand the feature from every perspective.
    3. When I feel I understand the feature pretty well I begin writing specs. Since we use specflow all specs become automated tests to test the system. Usually I begin by creating a list of all specs by title and then write each spec, one at a time. This is tedious, but invaluable. Often I would discover new edge cases and go back to domain expert to get additional info. Sometimes it’s scenario that expert haven’t thought of, so we discuss it and decide together how to best handle it. Also specs are nice since I can show them to the domain expert to verify my understanding.
    4. When all specs are done (and they all fail at this point) I work on contracts and domain tests. Usually by this point I have pretty good idea about commands and events (although perhaps not always what data should be in event). But again, I start with the list of cmds/events and tests.
    5. Once contracts and aggregates are done and domain tests pass I go back to specs. This is when I implement code for specs and any client projections I need (specs rely on client views to confirm data mutated as expected). This is also when I tweak events to include any additional info that can be useful for the views.
    6. When all specs pass – work on UI and put it all together.

    I guess the common theme is that I learn logic for a feature in several iterations, first by discussion, then by writing specs, then by writing contracts, aggregates and domain tests.

    re additional info in events: One pattern that seems to indicate which info I need to include in events relates to the business logic calculations. For example if I have command AddItem( 2 ) where 2 is quantity to add, simplest event is ItemAdded( 2 ). However logic inside the aggregate knows how to add items. So, if I already have 3 items, the end result is ItemAdded( 2, 5 ). And actually in my case it’s often ItemAdded( 2, ( 3, 5 )) to indicate the original value and the resulting value. So event carries command data (2) and calculation input (3) and output (5). This makes all events idempotent as well as makes it easy to create audit projections (to show how data changed over time).

    Hope this is useful. Cheers, Slav Ivanyuk

Leave a Reply

Note: You may use basic HTML in your comments. Your email address will not be published.

Subscribe to this comment feed via RSS