DDD principles in a visual designer? Part 1

Yeah, boys, I’m crazy to think about applying DDD to an application like this, but I feel that being so purist has some great consequences to my designs, taking some benefits from this way of thinking  about development.

Domain-driven design, taking as it sounds, is to put the focus on the domain. Think about the domain and about how the model HAS TO BE. Let the rest flow as you need it. Everything should be subsidiary (although it will be important, too).   Take the true essence of the domain of it and make a model.

That model can be simple or incredibly complex, but you have a model and you can talk about it using concepts and relations that flow naturally from it. The model is self-contained and has to describe any substantial change of the domain it represents. You can talk about it as a whole!

That’s really cool.

But there are situations where the model is a bit strange. What if the model is not a common entity like a Person, a Bank Account or a Product? What if you have to deal with entities that are commonly attached to the UI, the layout or part of a document, like a Paragraph, a Rectangle, a Field…?

Data Transfer Objects in Domain-Driven Design Patterns

Data Transfer Object. A simple pattern for exchanging information between the Presentation Layer and the Service Layer.

The basics are explained in lots of articles all over the web, but there are some details that are not so obvious. I implemented DTOs following my instincts, but I always had the feeling I was asuming things and not doing it well.

That’s whay I keep on asking about the insights of patterns like this.

I found a very interesting article about DTOs by Bozhidar. I recommend you to read it because it gives several hints and advices on how to use this pattern sucessfully.

Bozho’s tech blog – On DTOs

The last part I want to notice is the question I posted. As you see, Bozher was really kind and answered really quick.

Thanks!