about 2 months ago - 2 comments
When listening to many discussion about Domain-Driven Design and Event Sourcing, subjects which I am recently very into, sometimes I have a feeling that events are considered merely a way of persisting aggregates. People tend to discuss benefits events have with regards to storing historical data, having possibility to generate any read model out of [...]
about 3 months ago - No comments
I’ve spent some time recently renewing my old DDDSample.NET project. I understand that it is the projection of my subjective and uninformed view of Domain-Driven Design, but still I see a value in having some implementation compared to having nothing — it provokes discussion. That’s why I will continue to invest my time in it. [...]
about 4 months ago - No comments
As I promised in one of the previous posts, I am now in process of renewing the DDDSample.Net source code. It’s been quite a while since I published the first version of it. Many technologies have changed and my take on Domain-Driven Design and software architecture also has changed slightly.
First of all, the repo was [...]
about 5 months ago - 4 comments
A Domain-Driven Design sample I created some time ago, DDDSample.Net, is now a little bit rusty. I though it is a good idea to spend some time and make it up to date. It will involve, for sure, moving the project to github because you all know what I thing about TFS version control.
Currently there [...]
about 5 months ago - 9 comments
Starting a new project is fun. You (assuming you, reader, are The Architect) can make all the decision and do it right. You can use all the newest technologies you can find. And what do you do when it comes to designing business logic? Hopefully you base you decision on the level of complexity of [...]
about 5 months ago - 1 comment
Let’s talk about testing. How do you test your business logic? I spent some time thinking about it and came up with three different strategies for three different ways of implementing business logic.
CRUD
As you can read here, I think CRUD is OK for small and simple applications. You have to, however, remember what is not [...]
about 5 months ago - 3 comments
Quite often we see criticism of Create-Read-Update-Delete solutions. There are tons of blog posts why CRUD is inferior to Domain-Driven Design. I have probably written a few of them in my life. It seems like everybody is doing proper DDD and advocating doing it so where’s the problem? I haven’t seen so many domain driven systems [...]
about 5 months ago - 6 comments
The Repository pattern is one of the most popular patterns of enterprise application architecture (P of EAE, a great book by Martin Fowler). The pattern was further refined in context of Domain-Driven Design by Eric Evans. Since then wars has been waged around how to implement a Repository and when to use it. Here’s my [...]
about 1 year ago - 14 comments
Traditionally web applications are built using some sort of server-side framework like Rails or ASP.NET MVC. Such a framework provide means to implement business logic in a (hopefully) testable manner. Traditionally there are two approaches to shape this logic. One is to leave it close to the UI layer, probably in the Controller part of MVC [...]
about 1 year ago - 3 comments
Preface
The reality our our profession (mo matter whether you think it’s a craft or a trade or whatever) is that we are not always allowed to make the best and optimal decisions from technical perspective. There are situations when other factors are more important. These factors include things like:
what skills are there on the team [...]
and here 
) from the perspective of a single DTO object used to display some data. My point was that DTO is only one of the possible solutions to the problem of displaying data and, compared to CQRS, is in most cases not the best one.
about 1 year ago
Well, put. I’ve seen a number of people cite the additional complexity of CQRS as their reason for avoiding the pattern (which they often see as an architecture and not a pattern). While some agree CQRS is valuable they believe it is too complex and difficult to apply and most scenarios don’t warrant this overhead in complexity.
In my opinion, an my own experience, CQRS increases the simplicity and maintainability of a design. By seperating these concerns we gain much more fine grained control.
Where CQRS becomes more complex is when DDD (or DDDD in this case) is applied. In that case YMMV and if you don’t feel the situation is complex enough to warrant it then don’t use it. However CQRS does make applying DDD far simpler (in fact I would go as far as to argue it is nearly impossible to do DDD well without CQRS).