DEV Community

Discussion on: Is file parsing a domain operation in DDD?

Collapse
 
goyo profile image
Grzegorz Ziemonski

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.

Collapse
 
piczmar_0 profile image
Marcin Piczkowski

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.