InfoQ Homepage Presentations Domain-Driven Design with Clojure
Domain-Driven Design with Clojure
34:59
Summary
Amit Rathore shares advice in building large scale applications in Clojure, making sure the code is readable and maintainable.
Bio
Amit Rathore (@amitrathore) is CEO, Zolo Labs, a new Clojure/Datomic/Storm startup. Their first product is Zolodeck: a personal digital assistant for professional networking. Amit is the author of Clojure in Action, and also Chief Technologist at Runa, another Clojure-based big-data startup that uses machine learning, predictive modeling, and real-time targeted offers to increase eCommerce sales.
About the conference
Clojure/West is the newest conference creation from Alex Miller (aka @puredanger). Alex has been running the Strange Loop conference in St. Louis since 2009, smashing together the worlds of functional and dynamic programming languages, concurrency, distributed systems, web and mobile. Since early 2010, Alex has also been part of a team using Clojure at Revelytix.
May 27, 2013
Community comments
Good talk
by Duraid Duraid,
Missing important information
by Witoslaw Koczewski,
Re: Missing important information
by Joerg Schmuecker,
Good talk
by Duraid Duraid,
Your message is awaiting moderation. Thank you for participating in the discussion.
I enjoyed the logical progression of thoughts used to build a coherent picture while staying concrete and useful and not drawn in the moving sands of DDD.
Missing important information
by Witoslaw Koczewski,
Your message is awaiting moderation. Thank you for participating in the discussion.
What I am missing: Where do domain function get their data from? For example, if I have a Todo application and I want to implement a new feature: "delete oldest todo". Then my domain function needs to find all users todos. How to perform this query without a dependency to the persistence namespace?
Re: Missing important information
by Joerg Schmuecker,
Your message is awaiting moderation. Thank you for participating in the discussion.
If you always operate on the oldest, then you just pass in the oldest. If you sometimes want to delete the oldest and sometimes you want to delete something else, then the business logic is picking the right "filter". So you would split the problem into:
1) a function that returns the filter to test your condition
2) a function that interprets the filter for your underlying infrastructure. This could for example be emitting some code, for example the SQL statement you need to be executed.
3) a function that interprets the filter on a simple seq that you use when you are testing your business logic, see above for the code.
#1 is in the domain layer
#2 is in the persistence layer
#3 is part of the testing harness
I can't imagine a good business use case where you would want to delete the oldest message, that sounds more like a purge function which is probably best in the persistence layer in the first place.