I came across this article by John C. Maxwell. These ideas can be equally applied to software development.
Whenever a new technique comes to the fore it takes a while for it to settle in. Quite often one tries to apply it everywhere and that is when it seems as though it doesn’t always fit. Of course, one should at least try to give it a go but there are instances where it may just not be the right tool for the job. Command / Query Responsibility Segregation is one such an animal. It may not be applicable in every scenario. Now don’t get me wrong. CQRS really is the way to go but it works only when...
I have been struggling with many aspects of OO development over last couple of years, all in an effort to improve my software. I have, along with others, been trapped in the DDD Aggregate Root thinking that appears to be everywhere. It appears as though there is this opinion that ARs are the centre of the universe and I have come to the conclusion that it must have something to do with the consistency boundary afforded by an AR. This seems to have become the central theme. Almost as though it became necessary to define DDD in some structural sense....
Now I don’t particularly fancy any ORM. I can, however, see the usefulness of these things but I still don’t like them. One of the useful features is change-tracking. So as you fiddle with your domain objects so the ORM keeps track and will commit the changes to the data store when called to do so. Now let’s say I create an order with it’s order lines. My use-case is such that I have to call Customer.AddOrder(order). That is OK I guess but what about now storing the changes? What were the changes? For each use case I need to...
Right, so I have seen some examples of determining an order total by adding the totals for the order lines, and then applying tax, etc. Firstly, however, we need to determine whether an order would actually ever do this. Why? Because an order represents an agreement of sorts and is a near-immutable object. One typically starts out with a quote (or shopping cart). This quote may have items that are on special. We may even apply a certain discount (based on our client segmentation or a discretionary discount) to the quote. There will probably never really be any rules around...
I have been wondering whether an aggregate root should ever contain a collection of another aggregate root. Back to the Customer. Is it OK to have a collection of Orders? One could argue that a customer may have many thousands of orders after some time so it would be impractical. However, such a collection (in the domain) would mean that the customer only has a collection of the open orders. So in a real sense this list should never be all that big. Using CQS one may even remove the completed orders from the domain store. Even so, what purpose...
After some interesting to-and-froing on the Domain-Driven Design group the penny dropped on task-based interaction. Now this is something Udi Dahan seems to have been doing a while and it is actually very nifty. Now I must admit that I thought I actually understood task-based vs. entity based interaction but it turns out that even having something like ‘Activate Account’ is not necessarily task-based. Well, the UI would appear to be task-based to the user but how we implement this ‘task’ in the domain is where it gets interesting. For our scenario we will use a disconnected environment as is...
There has been some discussion around many-to-many relationships. Here is what Udi Dahan has to say: DDD & Many to Many Object Relational Mapping In his example Udi uses a Job and a JobBoard. As he states the typical modelling for this situation ends up with the Job having a collection of JobBoards and a JobBoard having a collection of Jobs. This is, as he states, somewhat problematic. He then reduces the relationship to a JobBoard having a collection of Jobs and a Job having no relation to JobBoards. This reduction of relationships is more-or-less what Eric Evans also states...
OK, I know Aggregate Roots (AR) are a consistency boundary but I believe that they need to do even more. As Eric Evans mentions in [DDD] relationships need to be scaled down to simple forms or even eliminated since it leads to simpler software. I agree. I think we, as developers, have managed to paint ourselves into a corner over the years and since some of our techniques have been developed over a long period we just don’t see it. It’s like the guy sitting on his porch with his dog lying next to him. The dog is moaning and...
I spent some time this past weekend thinking about how the OO development community has done its utmost to rid itself of high coupling within object models. It has, for the most part, been rather successful. So I got to thinking how there appears to be a high level of coupling when it comes to the actual data being stored; so coupling within the database structure. If one considers that a customer may be invoiced then an Invoice has a direct relationship to a Customer; hence, the customer foreign key resides in the invoice. This tightly couples the data. It...