Discussion on Object Modeling

start.md

https://twitter.com/ironchamber/status/464493062727950336

How much modeling is done up front, vs. iteratively?

As with anything it will depend on the context, and you will get a feel what works and what doesn't over time, but I can provide a few suggestions. For upfront design generally you going for breadth, rather than depth, so this translates to:

• find the majority of business objects in the domain
• identify collaborations between these business objects

From there you may choose one or two key scenarios (business requests) to test the model out. UML sequence diagrams are awesome for this. This will help to define some key business rules, assign key services and attributes.

The key with upfront design is to get a feel for scope and understanding the domain model at a high-level. Post-it notes are great for limiting how much detail you can add to a model. Here's an example from yesterday where I was simply finding business objects and identifying collaborations.

From there you can work on the domain model iteratively as you work from a backlog of user stories or features. Before starting the implementation of the feature I recommend revisiting the domain model. Again, you can test the domain model by walking through a scenario based on the user story/feature using a sequence diagram which will help you define business rules, and assign services and attributes. Of course, you may find once you have started implementation, a need to adjust your understanding of how the domain works. That is expected. However continue to work within the context of the four archetypes: events, roles, party-place-thing, and description.

(@ironchamber here - I should probably change my twitter username at some point ;) )

So do you feel like modeling like this can happen both in micro and in macro?

Like, the original pass of modeling would occur in an overview fashion, where we identify major components or operations. Afterward, we drop a level inward and work with our user stories to discover smaller moving pieces within each major component?

Or is it that the first pass is mostly a shallow examination, which we sort of shape over time into a more precise vision? Refactoring with user stories, at this point?

Using sequence diagrams is pretty interesting to me here - I'm curious what you do when in the absence of actual methods or functional units. Do you just use the sequence diagram in order to suggest the interoperation in a more abstract way?

My current approach is to take a shallow examination. Upfront I want to know what the business objects and the collaborations so I understand the language of the domain. Currently I'm involved in a rewrite of a patient observations application where the language is very specific, so developing a domain model makes sure I really have a good grasp on the domain language. I don't want to get bogged down in all the details, but I want a good map of where I'm heading.

Once I'm in development mode, I will refine my understanding of the domain model by examining business rules, services and attributes. Not so much of a refactoring, but another iteration of my understanding of the domain.

I use sequence diagrams to help me understand how the domain model is going to handle a specific business request. It helps test that the static class model I have does support the business request and identify any missing services I have. I could have used a sequence diagram in my presentation for how an order is shipped, but chose to use a communication diagram as I thought it was simpler for the presentation. The services identified are implemented as methods on a business object (model) in my application.

Using sequence diagrams is pretty interesting to me here - I'm curious what you do when in the absence of actual methods or functional units. Do you just use the sequence diagram in order to suggest the interoperation in a more abstract way?

I'm not sure if the above answers your question regarding sequence diagrams. If not, feel free to rephrase and I will give it another shot :-)

I don't want to get bogged down in all the details, but I want a good map of where I'm heading.

That's my exact issue when I go into upfront design of almost any sort - I get paralyzed with the details. Everything starts to look interconnected and every entry point into actual implementation starts to seem equally wrong. Inevitably the idea withers.

I'm kind of talking about personal projects, here - stuff I do for clients has the miraculous property of being external, so I find an easy way to identify the most valuable pieces first in terms of what I judge to be the best placement of my initial efforts.

So, it seems to me that you are recommending doing a sort of conceptual scaffolding, and then refining that with the insights you get from each pass?

I definitely mis-phrased what I meant when I was asking about sequence diagrams! Let me try again:

Let's say I'm in a situation where my client is presenting me with a fresh problem to the domain, and I'm interacting with them in a capacity of helping discover and build a system to help them explore this fresh problem. I normally yield to their expertise with the domain language, but neither of us have a firm grasp of this exact situation yet.

In this case, you've given me some thoughts about maybe turning towards a sequence diagram, as a way to concretely prove the presence of certain discontinuities in the overall process, but this would be almost in a brainstorming capacity - long before I would get a chance to start identifying entities.

Does that seem like a kludgy use of the wrong tool, for you? Is that me trying to be too clever with the diagram, is there a better approach? A more direct way to discover initial properties about my domain model?

Basically, my day-to-day operation is in a late-stage retail startup, and internally we are still very much feeling out what we're doing. I've been using a lot of modeling concepts (and starting to incorporate yours after Railsconf) in order to extract direction for a business intelligence toolset I'm building. So: If I'm still being vague or you are interested in more concrete examples, I can absolutely find some :)

btw, thanks for taking time to hang out and chat about this! It's been really cool

So, it seems to me that you are recommending doing a sort of conceptual scaffolding, and then refining that with the insights you get from each pass?

Yes, that's right.

Does that seem like a kludgy use of the wrong tool, for you? Is that me trying to be too clever with the diagram, is there a better approach? A more direct way to discover initial properties about my domain model?

Personally, I find a static diagram easier to understand the relationships in the domain and then I move to a sequence diagram to test and flesh out from there. When presented with a "fresh problem to the domain", I would approach it this way:

1. Identify and summarize new feature set
2. Optionally, write a design story describe scenarios within that feature set, this is a great way to start pulling out domain concepts for a static diagram
3. If applicable, mockup some screens to make the feature set more concrete
4. Create a static diagram by identifying events, roles, parties-places-things and descriptions.
5. Identify other systems the domain interacts with.
6. Test that static model with some scenarios from the feature set using sequence diagrams.

This is what generally works for me, I might mix that up a bit time from time.

If there's a concrete example that would like to work on, I would be definitely down with that. We can also try a Google hangout to make this a bit more interactive :-)

Ok! I've been trying to situate into using this methodology for the last two weeks. My journey went a bit like this:

First, I attempted to adopt the sticky-note situation, but I found that around my office we have very little amounts of space for sticky notes. I ran into this same problem with adopting an analog kanban.

In the kanban situation, I stopped kanban and began to use a bullet journal system. When that got a little too unwieldy, I then settled on using index cards and a sharpie. This worked great for quickly getting tasks out of my head and into the "real world", then sorting them in piles and collecting/discarding them when appropriate.

So, I opted to try the same process with color-based modeling.

First I purchased a set of pens in the appropriate colors, and attempted to use them in a dotted journal. I loved the way it looked, but it felt like it was more of a concretion step than a discovery step. I couldn't move things around when they didn't fit. I couldn't discard things when I realized they weren't necessary.

And, even worse, I couldn't find any yellow felt markers!

I've realized some really big things about the system, at this point:

• Objects have to be disposable in order to effectively model with them. I will probably always start out wrong and then shape things towards something less wrong.
• Conceptually, the colors really are important - orange (my compromise on the absent yellow pens) was just plain not as effective in distinguishing pieces.

I went back to the office retailer a few days later and bought some index cards. I got plain white ones and color coded ones. I snagged some sharpies of the appropriate colors.

Here's my current setup:

So, next week, I have a great opportunity to battle-test this: I am sitting down with a customer team and I'm going to help them collect and organize stories.

Once I have the stories, I intend to use color-based modeling to analyze them. The way I mean to travel through the process should look like this:

1. Jot down pieces and processes of the system which I percieve on the white cards.
2. Sort through them later with highlighters of the appropriate color.
3. Transfer the objects to the correct color cards later.
4. Begin to sort them in an analog way to discover the best orientation.
5. Transfer the final (first draft) to the journal for reference.
6. Reorganize from the top when appropriate.

The purple cards

I know it might be focusing overmuch on minutiae, but right now I'm wondering if there's some way I can use the purple cards to represent something inside my domain.

Although color-coded object modeling seems to not directly map to the patterns and processes laid out in Domain-Driven Design, I believe there is a clear intuitive link, and so my intention is to attempt to use the purple cards to represent out-of-boundary concepts. Infrastructure, or interfaces, mainly.