tag:blogger.com,1999:blog-8864435396524375431.post6257099153777787324..comments2022-12-12T00:21:25.652+02:00Comments on Систематизация автоматизации: Command-query separation — две стороны одной моделиIgorhttp://www.blogger.com/profile/10232785741897411593noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-8864435396524375431.post-47985632147016037292011-01-09T21:15:22.848+02:002011-01-09T21:15:22.848+02:00"Но откуда-то из вашего кода начинает нести о..."Но откуда-то из вашего кода начинает нести отборным code smell" класс, поржал, спасибо :)))Vladimir Gaevoyhttps://www.blogger.com/profile/06244183836973191364noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-23516225313529547292009-10-25T17:50:46.756+02:002009-10-25T17:50:46.756+02:00Ну... Как бы... да :)Ну... Как бы... да :)Igorhttps://www.blogger.com/profile/10232785741897411593noreply@blogger.comtag:blogger.com,1999:blog-8864435396524375431.post-69627466598339663832009-10-25T16:47:48.784+02:002009-10-25T16:47:48.784+02:00Вот ссылка на интервью, в котором обсуждается данн...Вот ссылка на интервью, в котором обсуждается данная проблема:<br /><br />http://www.infoq.com/interviews/greg-young-ddd<br /><br />Есть там, к примеру, такой кусок:<br /><br />QUESTION: <br />Are you suggesting that you only convert to the internal domain model when you write stuff?<br />ANSWER:<br />Absolutely, and it is a very common system architecture in general. If we were to look at a typical domain driven design based architecture, we would have - let's say - an application service sitting there. This application service is going to have probably some query in methods - things like I need to get customer information, so I can put up on the screen, that's why I'm going to have some command methods "I need to change this customer's address, too". All the command-query separation is to recognize that these 2 things exist and to separate them. They both do not need to go to the domain.<br /><br />Whereas the first one was going directly to a domain for the queries, we are just going to pull that across and we are only going to have our thin little DTOs, which we had before, but now we are going to populate them directly from some data source. It may or may not be the same data source that we write to. There may be 2 data sources and they may or may not be eventually consistent. Even if we start off with this single data source, we know that we have this ability to move towards an eventually consistent architecture layer, which will allow us for a large amount of scalability, if we needed that at a later point. Beyond that we've cleaned up our domain in terms of making a transactional only on the write side now. Our domain ends up cleaner, our DTO layer ends up cleaner and let me just say I would hate to be the junior programmer who has to write all the DTO mapping code - It's a pain! Been there, done that.<br /><br />But the domain code becomes a lot more interesting because you are only passing through a single direction. What I generally do - I will use a pattern as an event sourcing. I read my DTO's and then I create a physical command message based on the data in my DTO's and I send that message to the domain and then the domain will tell me whether it succeeds or fails. On the back end of this you can then move those same messages or you can have a separate event stream coming out of your domain and /or finish then close the loop.Anonymousnoreply@blogger.com