Domain-Driven Design
Updated: 4 min 51 sec ago
Tue, 09/07/2010 - 04:29
Hi Nuno, What I see is that there are two different things happening here: - Observation - Action So let's stick to the "real" world: For our 'observation'
Tue, 09/07/2010 - 03:59
Hi Greg, Third try and last. I think you will see precisely where we diverge perception. I'll use you cup example. Here is a recap. ... I agreed that the
Tue, 09/07/2010 - 02:48
Hi Mike, There is nothing innately wrong with transaction script. That being said, you should not assume that the "transaction script" in the repository is
Mon, 09/06/2010 - 17:02
I would argue that this is the wrong way. In this case your repository is becoming more of a transaction script (and you run the risk of having anemic
Mon, 09/06/2010 - 17:02
To be fair all of your requests will probably be retrieved in one round-trip select * from Requests req join Objectives obj on obj.RequestId=req.Id where
Mon, 09/06/2010 - 17:02
So this is where LINQ comes in. I'm not sure how well NHibernate supports this scenario but EF supports projections like this var address = (from order in
Mon, 09/06/2010 - 16:33
After watching videos from Greg Young and Udi Dahan I am finally starting to understand CQRS with Event Sourcing. At least I think so ;) I have some questions.
Mon, 09/06/2010 - 13:18
Let me walkthrough what we do now: How do you synch changes? <- The update event will will the in-memory datastore, for transactional data; and update the
Mon, 09/06/2010 - 12:52
Hi Greg, ... I understand that you disagree. I'll try better one more time. ... Maybe it is me that doesn't understand what the fuss is all about eventual
Mon, 09/06/2010 - 12:16
Imagine a "Phonecall" object. It's an inmutable object, that can answer you it's duration, its source and destination number, aaand that's it. If we assign
Mon, 09/06/2010 - 12:01
Hi Vaughn, Sorry for delaying, I usually don't get connected on weekends. Wife is time consuming :) ... I see the Context Map pattern as a clear solution to be
Mon, 09/06/2010 - 10:08
... Ah ... so what you are saying is: ... Assume data for different entities are spread out on different servers. Entity A is stored on Server X, and Entity B
Mon, 09/06/2010 - 10:01
... Err, sorry. Not in same memory as the application process. I was thinking about the individual shard servers having in-memory copies of their data.
Mon, 09/06/2010 - 09:26
To be clear, in many cases a network hit to load in a typical stateless way is not acceptable for various reasons (including latency). Mongo db with a set of
Mon, 09/06/2010 - 09:14
umm mongodb is not in memory in your process as was being discussed unless I missed some great new product named mongodb that came out. ... -- Les erreurs de
Mon, 09/06/2010 - 09:13
And for some inspiration: MongoDB sharding does all of this for you :-) Read "Life beyond distributed transactions":
Mon, 09/06/2010 - 09:12
"I'm not refuting the fact that the world act over inconsistent information. But the observer always act according to the with the infotmation observed." How
Mon, 09/06/2010 - 09:04
Hi Jorn, Yes, that is more or less what I did in my little sample. But in the end of the day in our context I just don't see the advantage of sending a command
Mon, 09/06/2010 - 08:59
How do you synch changes? Or if domain is too big for one server you have to add stickiness (likely a message router). In this case, how do you handle
Mon, 09/06/2010 - 08:51
yes for now our application are in single server for difference domain. however i am not sure what are the complexity specific for in memory datasource, would