I was writing an application following DDD and was confused on the following scenario.
I have a batch creation of the domain objects by uploading a CSV file in which each row has comma separated values of domain object attributes, e.g.
#name,surname,age
John,Smith,35
Betty,Johnson,56
Should I have an application service which will parse the file an only pass a collection of domain objects to a domain service or can I do the whole parsing in the domain service?
What would you advice? What is the most appropriate considering the DDD approach?
Top comments (21)
I thinks its a repository, since its getting data from a persistance store (the filesystem). You should call the repository method within an application service which orchestrates your use cases.
This.
?
It would make sense if it was really getting data from any storage, but I get it from file uploaded by user to my rest controller. It's in-memory, not in file system.
So i think you should parse it using a service/utility class, call this class within your controller, and pass the returned user objects as an usual parameter to your application service class, which would orchestrate your use case without knowloadge about the file. Treat the file as a controller parameter/input, despites the fact that your framework probably doesnt parse it by default.
Incidentally. What are the best resources to learn DDD?
I am a Rails developer and I am looking for methodologies to "transcend" MVC. I bought the book Domain-Driven Design Distilled by Vaughn Vernon, but I find it difficult to map the concepts to the development of a Rails WebApp.
Do you guys think that DDD would help me developing better organized business code? If so, what would be the best way to introduce myself to DDD?
I'll actually work backwards over your questions, as this seems to make more sense.
If you have read any DDD-related book already, then the introductory part is already done. It's time for a long process of applying it, failing, learning, and trying all over again. AFAIK there's no way around that, no matter how many learning resources you consume (although they can still dramatically speed up the process!).
Whether and how much DDD will help you in organizing (writing in general) your code, depends on the domain you're working in, the culture and processes of the company you're working for, and probably a bunch of other factors. That said, unless you're working on a technical, non-important utility project, kept separate from the domain experts by corporate silos, then you can expect some meaningful improvements in pretty much all parts of the code.
Mappings concepts between different patterns and techniques is always a non-trivial task, especially given our lack of discipline when it comes to terminology (basically, you'd have trouble to find a second person in the world who understands both MVC and DDD the same way as you do).
Complaining aside, I think that most people would agree that all the building blocks (aggregates, entitities, VOs, etc.) all go to the Model part of Rails' MVC. MVC, again in the Rails' understanding, gives you the separation of the business code (model) from all the web-related concerns (views and controllers). DDD tells you how to organize your model, how to name things, what are the relationships between them etc.
When it comes to strategic patterns, things are a little bit more complicated. If your application is a monolith, then the boundaries between bounded contexts might be simply directories in your model directory or any other way for you to tell which term comes from which context. If your high-level architecture is more complicated than that, then different contexts might be even separate applications.
All that said, whether I made things clearer or blurier, just give DDD a try. Start by trying to develop at least some Ubiquitous Language, either by just talking to the domain experts or using a technique like Event Storming (look into this one even if you're not planning to use it). Build something on top of that, even if you're not 100% sure it's the right thing, and then refine, refine, refine. In the meantime, don't stop learning. Grab a next book (the blue one is boring but brilliant), watch some videos online, read some articles. It's definitely a topic worth investigating further.
I hope this helps. If you have any more questions feel free to ask.
I totally agree with that. It's even harder to learn how to put DDD in practice when most of the online tutorials are simple CRUD applications structured around MVC and not around use cases.
I think It depends on the business of your app, is the parsing a real requirement for your domain expert? or they just need the export to be done in whatever format and in any order as long as it can be read again?
If the answer is the first it's likely a domain service either its an application service.
Actually, it seems like you're more interested in the data itself rather than the way it is parsed (json, csv, sql, ...), therefore it should be an application service that helps with concern of parsing the file. You can also define an interface with a method like
parseand depend on the interface rather than the actual implementation. This gives you the possibility to add more parsers (json parser, yml parser, ...) in the future (if you need to)As a service is better.
Yeah, but which service? application or domain?
Usecase service.
Your Domain is entity?
Can you give more explanation why this is better to put CSV parsing in use-case service? Why not in higher layer. E.g. I could get batch data from various sources, e.g. JSON list via rest controller in addition to CSV upload and if I had parsing or JSON conversion to a list of domain objects outside of my use-case service I would not need separate use-case methods for each of these but just single method taking a list of domain objects.
Make it as a usecase, name your 3 source as controller, and call the service. How about this?
If you like put it to your domain class I think is OK.
You could see Clean Architecture picture by Robert Martin.
To me, this looks like a case for neither an application service nor a domain one. If the parsing is super-short (like a single method) then putting it in a controller/app service is not a big deal. If it's more than that, I'd go for a separate object that parses CSVs which you then call from the mentioned controller/service.
Reading some answers I think I was not quite precise in my question. What I really ask is not if you put it in Service class, Domain class or Controller class but rather in which layer you would put it if you look at this diagram:
github.com/mattia-battiston/clean-...
I think it should be part of controller/adapter to transform the csv into domain objects list, which you can pass to app service.
In my opinion you should start by writting the application service and do the parsing there...
That also make sense, but usually when I do a DDD I start with domain and create hexagonal architecture (ports and adapters) and with this approach I came to conclusion that I just care about a list of domain objects and don't care yet how they will be provided (by CSV or JSON or other means) which still leads to your answer that CSV parsing remains in application service.
Interesting... I usually start from the application layer and that helps me to decide what should be part of the domain. For me is easier start with the things that are more concrete ... but well, each person solves the problems in different ways =)