tag:blogger.com,1999:blog-2643923222133320297.post64525554889573770..comments2024-01-04T08:28:38.475-08:00Comments on David Ron: Functional Programming and Domain Driven DesignDavid Ronhttp://www.blogger.com/profile/03498490798803568055noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-2643923222133320297.post-65370321707595812092019-07-16T12:42:46.942-07:002019-07-16T12:42:46.942-07:00First, what is an Aggregate : https://martinfowler...First, what is an Aggregate : https://martinfowler.com/bliki/DDD_Aggregate.html<br /><br />I'm not sure if aggregates have anything to do with transactions except for the fact that saving an aggregate to a database would typically create several insert/update statements one would want to enclose in a transaction.<br /><br />As for why they might be considered collections in FP - when data and the functions that operate on that data are kept separate, then what's left of an Aggregate is just a collection of domain objects that the Aggregate aggregates. The functions that operate on that collection would still be part of the Aggregate of course.David Ronhttps://www.blogger.com/profile/03498490798803568055noreply@blogger.comtag:blogger.com,1999:blog-2643923222133320297.post-15820400130248354552019-07-16T12:21:59.719-07:002019-07-16T12:21:59.719-07:00Why is it that aggregates are considered as collec...Why is it that aggregates are considered as collections? Isn't it an encapsulation of the transaction?Adrian Yagohttps://www.linkedin.com/in/adrianyago/noreply@blogger.comtag:blogger.com,1999:blog-2643923222133320297.post-42458512160775808042018-03-14T17:22:33.420-07:002018-03-14T17:22:33.420-07:00It depends on what you mean by "anemic domain...It depends on what you mean by "anemic domain modal" and which FP language you are using. Really, the problem people are trying to avoid is the loss of encapsulation that occurs when raw objects are being passed around in an OO system. So, if you have a way to achieve data encapsulation, you have a way to avoid an anemic domain model. <br /> Clojure can combine data and functions into a namespace that exports only the parts of the namespace that are safe for outside consumption. Doing this creates an abstraction that can be safe from the problems caused by the anemic domain model. Here's an example https://www.braveclojure.com/organization/David Ronhttps://www.blogger.com/profile/03498490798803568055noreply@blogger.comtag:blogger.com,1999:blog-2643923222133320297.post-9351292864439772312018-03-13T17:27:29.227-07:002018-03-13T17:27:29.227-07:00How do you prevent anemic domain model by combinin...How do you prevent anemic domain model by combining FP and DDD?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2643923222133320297.post-28508497797809471962017-06-02T09:03:48.889-07:002017-06-02T09:03:48.889-07:00There are patterns in FP that accomplish the same ...There are patterns in FP that accomplish the same single interface to a complex domain model. Lenses, for example, solve many of the same problem fairly elegantly. But, I don't believe that there is a single concept in FP that solves the suite of problems aggregates in DDD attempt to solve. What kind of coupling are you attempting to avoid? David Ronhttps://www.blogger.com/profile/03498490798803568055noreply@blogger.comtag:blogger.com,1999:blog-2643923222133320297.post-5777645148597390942017-06-02T05:43:53.066-07:002017-06-02T05:43:53.066-07:00Immutable types may be protected from external pro...Immutable types may be protected from external protection, but giving external clients visibility into the inner structure of my aggregate still introduces coupling, which can be avoided with OO encapsulation.Anonymoushttps://www.blogger.com/profile/14291037130636364469noreply@blogger.comtag:blogger.com,1999:blog-2643923222133320297.post-42359525902730229332017-01-06T12:59:31.401-08:002017-01-06T12:59:31.401-08:00Moving to FP and throwing out DDD is throwing the ...Moving to FP and throwing out DDD is throwing the baby out with the bathwater. It actually really dovetails nicely into the Free Monad + Interpreter pattern.Vashhttps://www.blogger.com/profile/10790682886197794590noreply@blogger.com