Some CQRS And Event Sourcing Questions
218 views
Skip to first unread message
Bennie Copeland
Jul 5, 2015, 1:07:09 PM7/5/15
to ddd...@googlegroups.com
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.
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?
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.
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.
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.
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?
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.
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.
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?
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.
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.
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.
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?
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.
Greg Young
Jul 5, 2015, 3:52:12 PM7/5/15
to ddd...@googlegroups.com
There are pros and cons :)
> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Studying for the Turing test
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Studying for the Turing test
Greg Young
Jul 5, 2015, 4:02:01 PM7/5/15
to ddd...@googlegroups.com
inline.
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.
>
> 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?
>
> 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.
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?
> 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.
> 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.
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.
> 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?
>
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.
>
Bennie Copeland
Jul 5, 2015, 11:37:50 PM7/5/15
to ddd...@googlegroups.com
Greg,
Thank you for taking the time to answer my questions.
3. For where to put the projection event handlers, I don't anticipate having anything beyond a webclient and so considered putting the projection event handlers there, but I haven't seen a lot of discussion or examples on structuring applications and wasn't sure if this was a valid way to structure mine. I was curious to how other people structure their projects. I'm looking to try and avoid any common pitfalls due to my inexperience by doing a lot of research and asking questions.
4. Right now my type is my schema and that is why I have the "contracts" assembly that other projects can reference as that was easiest at the moment. In cases where that is not possible, how do you normally document the schema to share with other groups? Word doc, JSON schema, XML schema, etc?
5. You're right, it is not directly related to CQRS. But I think it is indirectly related as a means to ensure that prior deployed schema and contracts are not accidentally modified in future releases. I guess a more related question is how do you ensure version consistency between releases? Unit tests? Locking the file in the source code repository?
6. I'll have to dig more into P of EAA. Right now, everything still looks like a nail.
Thank you for taking the time to answer my questions.
3. For where to put the projection event handlers, I don't anticipate having anything beyond a webclient and so considered putting the projection event handlers there, but I haven't seen a lot of discussion or examples on structuring applications and wasn't sure if this was a valid way to structure mine. I was curious to how other people structure their projects. I'm looking to try and avoid any common pitfalls due to my inexperience by doing a lot of research and asking questions.
4. Right now my type is my schema and that is why I have the "contracts" assembly that other projects can reference as that was easiest at the moment. In cases where that is not possible, how do you normally document the schema to share with other groups? Word doc, JSON schema, XML schema, etc?
5. You're right, it is not directly related to CQRS. But I think it is indirectly related as a means to ensure that prior deployed schema and contracts are not accidentally modified in future releases. I guess a more related question is how do you ensure version consistency between releases? Unit tests? Locking the file in the source code repository?
6. I'll have to dig more into P of EAA. Right now, everything still looks like a nail.
Greg Young
Jul 6, 2015, 7:14:52 AM7/6/15
to ddd...@googlegroups.com
On Mon, Jul 6, 2015 at 6:37 AM, Bennie Copeland
<bennie.r...@gmail.com> wrote:
> Greg,
>
> Thank you for taking the time to answer my questions.
>
> 3. For where to put the projection event handlers, I don't anticipate having
> anything beyond a webclient and so considered putting the projection event
> handlers there, but I haven't seen a lot of discussion or examples on
> structuring applications and wasn't sure if this was a valid way to
> structure mine. I was curious to how other people structure their projects.
> I'm looking to try and avoid any common pitfalls due to my inexperience by
> doing a lot of research and asking questions.
>
It is a valid way especially for tiny systems. Normally I would
<bennie.r...@gmail.com> wrote:
> Greg,
>
> Thank you for taking the time to answer my questions.
>
> 3. For where to put the projection event handlers, I don't anticipate having
> anything beyond a webclient and so considered putting the projection event
> handlers there, but I haven't seen a lot of discussion or examples on
> structuring applications and wasn't sure if this was a valid way to
> structure mine. I was curious to how other people structure their projects.
> I'm looking to try and avoid any common pitfalls due to my inexperience by
> doing a lot of research and asking questions.
>
personally rather host these in their own service (deployed
separately) but I have hosted services inside of a web app before.
> 4. Right now my type is my schema and that is why I have the "contracts"
> assembly that other projects can reference as that was easiest at the
> moment. In cases where that is not possible, how do you normally document
> the schema to share with other groups? Word doc, JSON schema, XML schema,
> etc?
>
done it as documents as well. I prefer using actual schema as when
someone wants to talk to me say from the jvm and I am in .net they can
generate most of their client.
> 5. You're right, it is not directly related to CQRS. But I think it is
> indirectly related as a means to ensure that prior deployed schema and
> contracts are not accidentally modified in future releases. I guess a more
> related question is how do you ensure version consistency between releases?
> Unit tests? Locking the file in the source code repository?
>
change except to read it. One of my favorite breaking changes would be
for a thermometer protocol
TempRead degrees=27
TempRead degrees=27
TempRead degrees=27
TempRead degrees=27
TempRead degrees=27
TempRead degrees=80.6 //WTF?
TempRead degrees=80.6 //WTF?
:)
Reply all
Reply to author
Forward
0 new messages