Our October meetup is another round table with Eric Evans. From our previous experience, we found that coming up with a list of discussion topics in advance works really well.

This is why I ask every one of you to come up with just one topic you would like to discuss the most, and post it here.

The more people suggest a certain topic, the higher on the list it goes. And of course we could take an explicit vote when enough topics are proposed.

We will use these topics not just for the October meetup, but for all future ones as well.

Thank you very much!
Vlad

---
These topics have been proposed during our August session:
- Do an experiment with Naked Objects
- Introducing DDD in projects with Big Ball of Mud ("Brown field")
- Pick a topic and discuss - round table discussion
- Go on FAQ-finding mission (look for interesting and frequently asked questions on the Yahoo group and collaborate on distilling the answers; we could take 15 minutes out of every meeting to do that)
- Read or watch a published experience reports and discuss
- Role-playing workshop
- Exercise to implement Domain Event
- Do something with the Sample App (maybe convert to Naked Objects or Qi4J)

Introducing DDD in an established codebase. This is related to the "Introducing DDD into BBOM" topic but quite different in that in this case, we're not quite certain how "muddy" the code base actually is. In fact, it seems there are some relatively consistent models at work but the language isn't ubiquitous, the model isn't driving the design, key concepts are hidden, etc.

I suspect that the majority of developers will be involved with an established codebase instead of a green field project. DDD is probably just as important though.

Several topics that are not necessarily of a technical nature, but may be helpful to people who would like to see DDD adapted on a bigger scale within their organizations.

* "Selling" DDD to the business/management
* How to articulate advantages to get the buy-in from the management given that perceived ramp-up time and ongoing effort may be higher
* what is the minimal level of management buy-in required to be able to introduce and practice DDD within organization successfully

thanks,
- Ed Y.

Here are some questions I would love Eric to talk about:

Is Ruby and its expressiveness a good language for Domain-Driven Design? It seems most of the production-level Ruby code is mostly utilizing Rails. Unfortunatelly Rails promotes the ActiveRecord pattern, which tightly couples domain objects to ActiveRecord::Base. One could implement a facade around the ORM in the form of an anti-corruption layer, but then you would be forced to make changes in two places whenever you changed your domain objects.

Are there any new concepts that seem fundamental to DDD that are not in the book as DDD has evolved?

Does BDD have a place when implementing a domain model and if so can what value does it provide?

How does one deal with pieces of code that seem like they should be left out of the implementation of the domain model (such as logging)? AOP?

Should DDD naming conventions be used when implementing the domain model (e.g. OrderService, OrderFactory, OrderRepository)? Perhaps its better to use words that are more aligned with the domain?



Thanks,
Mike

* "Selling" DDD to the business/management
* How to articulate advantages to get the buy-in from the management given that perceived ramp-up time and ongoing effort may be higher

I'd be open to any of the suggestions mentioned, but I thought these two ideas from Ed were particularly relevant for me.

Thanks,
- John