tag:blogger.com,1999:blog-8719681132976995460.post5412298497675918390..comments2023-10-01T12:56:56.563+02:00Comments on Write less, do more!: Reactive DDD with AkkaNewionhttp://www.blogger.com/profile/11572139137150312052noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-8719681132976995460.post-40182226303506490842016-05-31T09:32:50.456+02:002016-05-31T09:32:50.456+02:00Expressing a failure with an exception is a widely...Expressing a failure with an exception is a widely-used approach. In context of the akka-ddd, it is also easy to read, write and test. Paweł Kaczorhttps://www.blogger.com/profile/02373761609879360567noreply@blogger.comtag:blogger.com,1999:blog-8719681132976995460.post-91939970918825151142016-05-31T09:12:17.929+02:002016-05-31T09:12:17.929+02:00I see in your sample code that you use exceptions ...I see in your sample code that you use exceptions to indicate a failure to validate a command. Why did you go with this approach?Anonymoushttps://www.blogger.com/profile/05816700174500882415noreply@blogger.comtag:blogger.com,1999:blog-8719681132976995460.post-48779443347479432162014-06-19T16:33:00.434+02:002014-06-19T16:33:00.434+02:00Hi Pawel,
Thanks for your detailed reply. In my ...Hi Pawel,<br /><br />Thanks for your detailed reply. In my case, such an example would be a financial contract. Contracts can contain quite a lot of somewhat peripheral information, and I agree that in terms of a contract aggregate root, only those properties that are required for validation and processing of events should be specified.<br /><br />But what to do with the peripheral information - maintain it in a key-value or JSON payload? Other areas of the system may need to access this information (preferably without sending a message to a contract aggregate actor simply to get the value of a couple of properties). Is this a case for maintaining the data within the contract AR through STM or in-memory datagrid?<br /><br />Regards,<br />SteveFreecloudhttps://www.blogger.com/profile/15432677964650970001noreply@blogger.comtag:blogger.com,1999:blog-8719681132976995460.post-25782376680669001642014-06-08T10:25:27.789+02:002014-06-08T10:25:27.789+02:00Hi Freecloud,
- first of all you need to decompose...Hi Freecloud,<br />- first of all you need to decompose your system into subdomains (bounded contexts) to be able to identify and design Aggregate Roots. Not every subdomain needs to be modeled using DDD technics. DDD should be used for not trivial (core) domains. Usually core domain has limited number of properties.<br /><br />- AR should contain only properties that are necessary for constraints validation (ONLY constraints inside boundary of AR) and behavior execution (i.e. no derived properties)<br /><br />- changes to AR state can be manifested by change of type of AR state (DraftInvoice -> SentInvoice -> PaidInvoice , all subclasses of Invoice, so no need to keep property indicating current state of invoice)<br /><br />- technical properties (AR actor dependencies (i.e. domain service actors)) are separated from business properties (properties of AR state)<br /><br />- when domain is decomposed into multiply ARs, ARs become thin (as dictated by single responsibility principle)<br /><br />- but in asynchronous environment this means you must embrace eventual consistency<br /><br />You can visit https://groups.google.com/forum/#!forum/dddcqrs to find more information on this subject.Newionhttps://www.blogger.com/profile/11572139137150312052noreply@blogger.comtag:blogger.com,1999:blog-8719681132976995460.post-41534000038204691762014-05-29T15:54:37.670+02:002014-05-29T15:54:37.670+02:00Hi Pawel,
Great articles, nice to read.
What hap...Hi Pawel,<br /><br />Great articles, nice to read.<br /><br />What happens when you need to create an aggregate with many properties, e.g. twenty or thirty properties? <br /><br />If I follow your sample code, I end up with aggregate states, and "creation" commands/events that have huge constructors. <br /><br />Also, how would one handle the case where a lot of such properties were of no consequence to the business logic, but simply needed to be stored so that they can be used later?<br /><br />Thanks,<br />SteveFreecloudhttps://www.blogger.com/profile/15432677964650970001noreply@blogger.comtag:blogger.com,1999:blog-8719681132976995460.post-55789672115969262142014-04-20T22:25:22.447+02:002014-04-20T22:25:22.447+02:00Is your worry about storing events (thus way more ...Is your worry about storing events (thus way more records than with "1 record = 1 entity")?<br />If so then the answer is usually snapshots. Akka also has built in snapshotting, so you wouldn't replay all 1b events, but only these from the latests snapshot (and the snapshot acts like "state of this thing, until this point in time"). When you have a snapshot, you could migrate data from "before the snapshot" to another datastore aimed for historical analysis etc.<br /><br />I hope this helped a bit :-)<br />Feel free to ask here or on the akka-user mailing list about design concents with DDD / Akka.Anonymoushttps://www.blogger.com/profile/03139337024949011769noreply@blogger.comtag:blogger.com,1999:blog-8719681132976995460.post-18599693843760786892014-04-20T07:50:01.895+02:002014-04-20T07:50:01.895+02:00What I still dont get about this DDD concept is ho...What I still dont get about this DDD concept is how you deal with 1 billion records.Leohttps://www.blogger.com/profile/15292881942016142210noreply@blogger.comtag:blogger.com,1999:blog-8719681132976995460.post-65321398308989087902014-04-19T21:01:09.384+02:002014-04-19T21:01:09.384+02:00Nice one, can't wait to see more of these!
//...Nice one, can't wait to see more of these!<br /><br />// Maybe include small snippets of mentioned code in the post, along with links to the file on github? Anonymoushttps://www.blogger.com/profile/03139337024949011769noreply@blogger.comtag:blogger.com,1999:blog-8719681132976995460.post-76890019268058179822014-04-19T01:59:42.328+02:002014-04-19T01:59:42.328+02:00Nice!
Please tell us moreNice! <br />Please tell us moreSébastien Lorberhttps://www.blogger.com/profile/16535575273136501866noreply@blogger.com