inline.
> I'm starting out with cqrs and event sourcing and have a few questions.
>
> 1. What information would you consider "out of band" and put in the event
> message header compared to the body? Things like datetime stamp, user id,
> etc.
security context is a good example. what ip did this come from?
another example might be username or ip address. The determination
basically rests upon what is the business event vs what is associated
with it.
> 2. What is common information that you would include in either the event
> message body or header? Anything beyond what Daniel Whittaker listed in
> number 5 here?
see ^^^
> 3. For the read side, it seems like the projections are very tied to
> specific screens in the client application. So would you have a single
> assembly/jar that creates the projections needed for all clients, or is it
> better to put the event handlers in the clients themselves? I can see some
> pro's and con's to each, and the answer is probably "it depends", but I'm
> wondering what others are doing.
Both are ok. Can you explain more your particular problem?
> 4. How do you typically structure your projects? In my current Visual Studio
> solution, I have a Core.Common.Contracts assembly that holds the interfaces
> and base class implementations for common domain objects like "command",
> "event", "aggregateroot", etc. I then have the bounded contexts broken into
> Core.SomeContext and Core.SomeContext.Contracts projects. The
> Core.SomeContext holds the domain models and the application
> services/command handlers. The Core.SomeContext.Contracts holds the
> DTO's/Boundry Interfaces/Commands/Events. I worry that my subfolder
> structure is too specific though as I feel like I have to pull in too many
> namespaces in order to tie things together though. Right now it is broken
> down by the type of object. Messages.Commands, Messages.Events,
> Messages.Responses, Models.Module1, Models.Module2, Presenters. I was trying
> to follow and Uncle Bob clean architecture pattern.
Remember that your types for dtos/commands/events are schema not
really types. You can also handle them in other ways. I wouldn't worry
too much about this as its details.
> 5. Where can I find good material on application lifecycle management? I'm a
> self taught developer and I've either been the lone developer, or developing
> was the side gig to my primary job. I've never had the chance to work as a
> junior on an experienced team to learn certain skills. When do I version a
> DLL, should I even worry about versioning a DLL for an ASP.Net site, how
> should I tag a release in git, what IS a proper release process? My current
> process is not very formalized.
This is totally unrelated to anything with cqrs; I would suggest googling more.
> 6. I've seen it mentioned several times that DDD is not for everything. Is
> that for DDD in its entirety, or just the strategic portions? I was drawn to
> both Uncle Bob's clean architecture, and then to DDD by their formalism. I
> read Implementing Domain Driven Design and learning the tactical patterns
> like separating things into entities, aggregates, and value objects really
> opened my eyes to how I could improve my own object design. I knew about
> things like DRY and the SOLID principles and tried to apply them to my own
> classes, but learning about value objects just blew me away. I had never
> before considered making the object identity a typed value class and the how
> that both clearly describes the object and takes advantage of the type
> system to prevent possible bugs. Or using them to connect objects together
> instead of direct references. I can't imagine a better way to construct
> objects now than using the tactical patterns. So, why do I see it said that
> DDD is not for everything?
>
To be fair its any object oriented design. Quite often an anemic model
is good enough. There are many options on any problem don't think DDD
is the only tool in your box.
> And Greg, if you are reading this, if you respond to a question with "there
> are pro's and con's to either" can you please, please, PLEASE, say what some
> of them are? I've seen that same response to several other questions when
> searching for answers, and for us new to ddd/cqrs/es, we/I lack the
> experience to be able to derive those on our own.
>