Greg Young [MVP]

Delegate Mapper

Greg — Sat, 03 Oct 2009 11:27:11 GMT

When I was in Holland Jelle Hissink pointed out a quick easy piece of code that is extremely useful in many scenarios I have seen in the past. It maps delegates from Base classes to Derived classes. Previously working with messaging I used the Handles<T> methodology which has since become popular in both MassTransit and nServiceBus. It allowed you to use typed message handlers as opposed to having to write handlers that used the base class then casted to the specific type. This code does the same but using delegates which is pretty slick and can be used in an aggregate root base class quite easily to handle the mapping of events to methods that apply them internally (you can also use it for event/command handlers if you don’t want to use an existing framework such as nServiceBus or MassTransit). Here is the code.

public class DelegateAdjuster
{
    public static Action<BaseT> CastArgument<BaseT, DerivedT>(Expression<Action<DerivedT>> source) where DerivedT : BaseT
    {
        if (typeof(DerivedT) == typeof(BaseT))
        {
            return (Action<BaseT>)((Delegate)source.Compile());

        }
        ParameterExpression sourceParameter = Expression.Parameter(typeof(BaseT), "source");
        var result = Expression.Lambda<Action<BaseT>>(
            Expression.Invoke(
                source,
                Expression.Convert(sourceParameter, typeof(DerivedT))),
            sourceParameter);
        return result.Compile();
    }
}

Simple, and slick.

DDD Step by Step

Greg — Mon, 31 Aug 2009 03:22:47 GMT

I don’t know how many people already know about this but figured I would put up a post about it as a pointer for those who have not seen it.

I was surfing over at DDDStepByStep.com and there are *a lot* of new resources available there for people who are learning DDD. Casey ~~Charaltan~~ Charlton :) is the one who has put it together and there is really some valuable information there. As an example he has (recently?) put up this about 50 page PDF that is a short book on getting started with DDD including many code examples. It also seems to contain a pretty good blog roll that can be subscribed to for those that are interested in DDD.

DDD is a dense book

Greg — Thu, 13 Aug 2009 17:42:00 GMT

But seriously there is some classic humour if you look hard enough. My friend Matthieu Guyonnet-Duluc sent me this scan today definitely worth a smile.

Command Query Separation?

Greg — Thu, 13 Aug 2009 05:07:29 GMT

There has been a lot of talk lately about Command and Query Separation. One thing that has come up with many people in learning it is that they get confused between CQS [Meyer] and CQS [Architecture or DDD]. As such many have called for us to rename the latter to something different as although it is very similar to CQS [Meyer] they find it to be quite different. I however disagree with this let’s look at our definitions.

Meyer:
Separate command methods that change state from query methods that read state.

Current:
Separate command messages that change state from query messages that read state.

The reader should notice that these two are nearly identical, the principle has remained the same, only the definitions of what commands and queries are has changed. A really quick reader will also be quick to jump on me for not bringing in all of what CQS has come to be known as.

In CQS [Architecture/DDD/whatever] we also go one step further and we create two end points (or objects) by splitting the responsibilities of the original concept. We give one sub-concept the responsibility of processing all of the commands and another the responsibility of processing all of the queries. We do this because we have come to understand that there are very different non-functional requirements for each and that by separating the two we can better tailor solutions.

One question that has been hitting me is whether or not this is something that may work as a pattern at the object granularity as opposed to the endpoint as many of these types of patterns are relevant to both scopes.

This part is new and is not CQS [Meyer] I am going to throw out a quick pattern name for this and call it Command and Query Responsibility Segregation or CQRS as we are in fact simply taking what would usually be one object and splitting its responsibilities into two objects.

So the first step is that we apply CQS as a principle, and we then come through and apply the CQRS pattern in order to end up with what people are currently calling “CQS”. I would hope that this is a clearer explanation and manages to bring in the original intent of command and query separation while realizing that there is in fact an important difference.

Does this help clear things up or does it only make things more confusing?

Unshackle Your Domain

Greg — Wed, 15 Jul 2009 20:21:26 GMT

Many people have asked me for links to this video. It has been up on infoq for a week or two now. http://www.infoq.com/presentations/greg-young-unshackle-qcon08 this is from last fall in SanFran for QCon.

The Anemic Domain Model Pattern

Greg — Wed, 15 Jul 2009 20:10:39 GMT

OK so I assume that you have run into the Anemic Domain Model Anti-Pattern at some point or another likely here on the bliki.

To quote from the bliki

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

What if I were to tell you that there are times and places where gasp an anemic domain model were in fact a best practice that would be highly recommended to a team? I really do vision the pitchforks and torches coming at me when I say this … Many including myself have lambasted unmentioned groups for pushing people towards anemic domain models so ….

Making the case

To start with let’s analyze why you were using that domain model in the first place. Ideally you were using it because it provided you the benefit of being able to effectively handle more complexity as opposed to a system like active record or transaction script. In other words you found your system was too complex to be modeled in a more procedural way. This complexity is often seen by analyzing the duplication of code in your more procedural transaction script based system.

Of course I find it rare to hear people cite this as why they are using a domain model. The reasons I hear tend to be more focused on the layering that necessarily comes with having a domain model. Instead I hear reasoning like testability, maintainability, abstraction from persistence mechanisms, strongly defined contracts etc.

Where am I going with all this what happened to the anemic domain model pattern? Well it depends why you wanted a domain model in the first place. If you are using a domain model in an object oriented way to help you in the managing of complexity it is absolutely an anti-pattern for you to be seeing an anemic domain model. What if you are in the IMHO much larger group that is mainly seeking the benefits that come with a domain model in layering?

The simplest in me would say that we would need to then compare the anemic domain model with other mechanisms to see if it would derive any benefit. We can pretty easily gain over a classical Active Record pattern because we can better express what is happening (especially in cases where we have an existing data model as we can map the data model if we want to). This leaves us with the more interesting case of transaction script, I deem the case “interesting” as both models are in fact transaction script we are comparing transaction script over an object model vs transaction script over say table module.

I would say that even in this close distinction that the anemic domain model can have some advantages. At the least single property level validation tends to be encapsulated within the object. This although really a slight step towards having a functional domain model can offer huge gains in terms of dealing with transaction script where all of the validation is distributed. There can however be other advantages such as the ability to more easily test in isolation and the long term maintainability of the system.

Defining a context

So the real question becomes can we define a context where purposefully creating an anemic domain model would be a good idea over our alternatives?

We want a layered architecture. We understand that our application due to non-functional requirements will need the benefits that a layered architecture provides. We understand the cost of creating a layered architecture and it has been justified by the stakeholders of our project.

Our domain is not extremely complex. This is a bit of a misnomer, but let’s say that our domain falls within the bottom 90% of systems in terms of domain complexity. There are likely some spots of higher complexity that we may focus more on (and perhaps even model in a more object oriented way).

Our team is not highly functional in object oriented design and analysis. When I say this I mean that team members must be highly functional in order to attempt creating a domain model (all other attempts will be doomed to failure, likely as an anemic domain model). When I say highly functional I would consider the AJM model (and people at the least being journeyman with maybe a single apprentice as the complexity of the system increases the number of masters needed increases). Said bluntly, 90% of teams in the Microsoft world should be looking at building anemic domain models as opposed to actual domain models for solely this reason. Using things that the development does not have a large understanding of is a certain recipe for failure.

We would otherwise consider a simpler model such as transaction script but feel that we can benefit from things such as further testability.

I believe that using these five viewpoints we can effectively create contexts within it makes perfect sense to be choosing to create an anemic domain model.

Always Valid

Greg — Fri, 22 May 2009 13:08:40 GMT

Jeff Palermo recently wrote up a blog post about “The fallacy of the always valid entity”. This post is a more thought out commentary to the ideas therein and could be better suited with a name of “The fallacy of the fallacy of the always valid entity”.

Jeff appears to be arguing with something that he for lack of better terminology just does not understand. He gives an example and then asks the question of:

“The fact that name is required needs to be context-bound. When is it invalid?”

This is referring to one type of validation that occurs within a domain. This is a validation to perform an operation. Generally speaking this type of validation is not performed by the object itself but is represented as observations of that object by another object. Jeff is right in that trying to make these things always valid makes no sense.

Of course no one in the “always valid object” camp has ever made such a statement. This brings us to the crutch of the argument … What do we want to keep valid?

==?

Not surprisingly some great people have dealt with these problems in the past.We can look at by going into philosophy (yeah boring I know) for a moment. Let’s say there are two horses a big Clydesdale and my friend’s daughter’s pony “samantha”. We have all seen the Budweiser commercials so we can imagine what the Clydesdale looks like but “samantha” is quite different. She is short, kind of thin, white with a black nose, and has her hoofs painted most of the time (likely due to her proximity to my friend’s daughter).

If we were to look at these two things we know that they are both horses. But they are still quite different, why is that? Plato put forth the concept of ideals, that there is somewhere an ideal horse which represents all of the recognizable traits of a horse. All horses can be descended from the one ideal horse, the ideal horse represents all of their common traits.

So you must be thinking how does this relate back to the original topic of objects always being valid? We have introduced a second type of validation!

Suppose we had a unicorn with no horn? Would it still be a unicorn? What about a cyclops with two eyes? These things are invariants of the objects (they belong on the concept of the ideal). If we were to have an object that did not meet these invariants it would in fact cease being the concept that we knew it as.

We run across these types of things regularly in our domains! Let’s imagine we are building grain silos … could we have a grain silo without a capacity? If we were writing poker software could we have a poker table without any seats? For a product application does it make sense to allow a sale line item without a product?

It can be quite useful for us to model our domains using invariants. The main reason for this is that it helps with DRY. Quite often we will see that nearly all or all operations require a certain thing to be true, as such the checks are run in many places. As an example a customer must have a name to place an order, they also must have a name to move, or to open a credit account. We could always be diligent to check that the customer has a name in various contexts or we can build into the customer object the invariant that the name will always be non-null. Invariants help us to narrow our thinking when we rationalize about our domain.

TDD will quickly lead you to the need for invariants. Consider when I have a BattleService that takes a parameter of a Cyclops … Without using invariants the first test I should be writing is should_throw_not_a_cyclops_exception_when_cyclops_has_two_eyes() … As soon as I find myself writing this test I should be seeing the language and realizing that I am being silly. In case that does not work I should at the least see that if I moved such a thing to be an invariant of my object that I could be saving myself code/tests elsewhere.

Now to bring this back to Jeffrey’s original misunderstanding of the always valid viewpoint, it is not that an object must always be valid for everything, there are lots of context based validations… Always valid means that you are not breaking your invariants.

Alt.Net Vancouver Edition

Greg — Wed, 20 May 2009 15:44:00 GMT

Registration is now open

Come to devTeach and stay for Alt.Net

Java vs .NET Developers

Greg — Tue, 28 Apr 2009 14:49:44 GMT

Davy Brion has an interesting post discussing his recent interviews with .NET and Java developers. I have to say that I agree with some of his assessments. Much of what we discuss in .NET is far more common in Java as Java has a far healthier community than Microsoft. You will find terrible developers on both side but the terrible developers on the Java side have more mainstream exposure to good ideas than on the Microsoft side.

The majority of the .NET community is fake as well, led by the leash by Microsoft. I remember in particular a discussion with quite a few people in Atlanta just after Katrina when I was there for a while where I was being laughed at and talked down to (the same tired arguments about sprocs) for suggesting the use of an ORM, these are the same people who today will reiterate the same arguments and push themselves as “ORM experts”.

How to we break out of this? I had great hopes for alt.net doing this but sometimes you feel like the engineer of a freight train who can see that truck 1/2 a mile ahead and has hit the breaks but is not hoping. I believe alt.net has at the least given the small few who were doing such things already a community upon which they can draw support from when they realize just how bleak of an abyss the .NET development world is. Over time new people will continue to populate alt.net and it will grow but because of the dynamics of the general community we will either need a revolution against Microsoft or Microsoft will need to lead the charge.

The drag and drop developer

A sub-theme to the post is the putting down of “drag and drop” developers. It is obvious that Davy in his scenarios values highly things like understanding DI and the SOLID principles. I agree that these things are very important, in some contexts!

“Drag-n-drop of pure visual components is usually not a big deal… drag-n-drop of data sources on pages or forms or whatever is a different matter entirely “

The typical arrogant developer viewpoint … likely the same kind of developer who would build DTOs on top of a domain layer to support a simple forms over data web application. There are contexts where dragging and dropping datasources can be extremely effective.

When people are attempting to use DDD one of the first things I tell them is not to, there are simpler ways and most applications do not justify the expense and complexity of DDD. Can we make a similar argument for development as a whole? Think about the systems that sharepoint is replacing today… Are they being “well crafted”? probably not but they are providing near immediate value at extremely low entrance prices. To help us further identify such systems, they are generally low risk and highly volatile.

The big problem with drag and drop development is not inherent within it but when it is applied to situations that it is inappropriate for.

Microsoft has made this possible with the creation and promotion of the drag and drop developer. These developers lack education, they are easy to bring in, they can produce value almost immediately, and cost a fraction of what a true engineer would cost. There is a vast number of systems that these developers can be extremely productive on while carrying little risk to the business as a whole. They also free up engineers to work on more interesting systems.

If we want to be effective architects one of our main goals should be to isolate these types of scenarios and build bubbles around them so we can use the lower skilled work force (at lower cost) without forcing our entire system to look like this. Remember that cost and scalability of a team is a non-functional requirement that we should be optimizing as well.

More on Repository

Greg — Fri, 24 Apr 2009 19:10:09 GMT

Oren has since responded so let me in turn respond. Its something that we will never agree upon because we have been in such different contexts.

He starts by saying

First, careful re-reading of the actual post doesn’t show me where I said that the repository pattern is dead. What I said was that the pattern doesn’t take into account advances in the persistence frameworks, and that in many cases, applying it on top of existing persistence framework don’t give us much.

I am sorry the exact statements were … “Repositories are a FAD" and “Repositories are the new Singleton”. I incorrectly used the term “dead” but the other statements are just as sensational to me.

Of course I have already rebutted the argument that is being presented that it doesn’t take into account the “advances in persistence frameworks” by bringing up the fact that it represents a LAYER/TIER boundary in an architecture. To this Oren replies:

Hm, I can see Greg’s point here, but I am not sure that I agree with him here. I would specify it differently .Service boundaries are procedural (be it RPC or message based, doesn’t matter). But a service spans both layers and tiers, and I am not going to try to create artificial boundaries inside my service. And yes, they are artificial. Remember: “A Repository mediates between the domain and data mapping layers…"

The boundary is not arbitrary or artificial. The boundary comes back to the reasons we were actually creating a domain model in the first place. it seems what Oren is actually arguing against is not whether “advances in ORMs” have changed things but that he questions the isolation at all. The whole point of the separation is to remove such details from our thinking when we deal with the domain and to make explicit the boundaries around the domain and the contracts of those boundaries. If you want further reasons read up on Hexagonal (Port/Adapter) architectures they are very well explained (note these are sort of like the “onion architecture” which was just a restatement of these ideas …. still waiting on that post to show the differences Jeff).

If we take Oren’s advice, we can store our data anywhere … so long as it looks and acts like a database. If that is not the case then oops we have to either

a) Make it look and act like a full database
b) Scrap our code that treated it as such and go back to the explicit route.

Just to be clear on this point … He has baked in fetch paths, full criteria, and ordering into his Query objects so any new implementation would also have to support all of those things. Tell me how do you do this when you are getting your data now from an explicit service?

Do all systems need to have ports/adapters around data access? No! but these same systems are likely good candidates to not be using a domain model but to instead be using one of the many simpler mechanisms out there. When you pop the bubble that has been built around your domain why not just do it again? who needs application services, we can just bind directly to domain objects …

Oren backs up his beliefs with YAGNI

I am going to call YAGNI on that. Until and unless I have that requirement, I am not going to think about that. There is a reason we have YAGNI.

Its not just about YAGNI its about risk management. We make the decision early (Port/Adapter) that will allow us to delay other decisions. It also costs us next to nothing up front to allow for our change later. YAGNI should never be used without thought of risk management, we should always be able to quantify our initial cost, the probability of change, and the cost of the change in the future.

In this case we have an initial cost which is the creation of thin repository classes that encapsulate our query objects (see Generic Repository post for example). These cost us nothing to create up front as compared to what Oren is showing… Literally minutes, especially when using command/query separation! What is the probability that we will have to work with a data store other than a database in the future? Say a tier boundary to a data service? This can change depending on your scenario … What is the cost if it happens, this is the key. the cost is large.

I think it becomes more obvious what the problem is when Oren defines a Repository as

A repository is a gateway to the actual persistence store. The persistence store itself may be another service, it is usually a remote machine, and the interface to that is by necessity pretty procedural. Trying to model a repository on top of that would by necessity lead us to procedural code. But that is a bad thing.

This is not a Repository this is generally a DAO. Repositories only give collection semantics to the domain, they SHOULD NOT contain the implementation I have gone through this in the past in a post I referenced in my last The Generic Repository. When you view a repository in this way things start to make more sense.

Continuing along…

A simple example would be a shopping cart, and the following commands:

AddProduct { ProductId = 12, Quantity = 2}

This require us to check if the product already exists in the cart, so we need to load the Items collections

Purchase

We can execute this with properties local to the shopping cart, so no need to load the items collection, this just charge the customer and change the cart status to Ordered

As I said, this is a simple example, and you could probably poke holes in it, that is not the point. The point is that this is a real example of real world issues. There is a reason why IFetchingStrategy is such an important concept.

Let me point out a large failure in logic here. You assume an impedance mismatch with a relational database that results in a much higher cost of getting the children with the parents. If I am using other mechanisms like say storing the ShoppingCart as a document in CouchDb that the cost will be nearly identical whether I bring back only the Cart or the Items.

Evans was very explicit in talking about aggregate root boundaries in that we need to consider them to be wholely loaded or not loaded at all. The whole concept of fetching strategies is nothing but a micro-optimization for a specific scenario … Relational Databases … If you are getting to the point where you absolutely need fetching paths you probably have your aggregate roots defined incorrectly and should use it as a smell to revisit them. I may have to revisit this in another post.

That is leaving aside that like all architectural patterns, CQS is something that you shouldn’t just apply blindly. You should make a decision base on additional complexity vs. required scope before using it. And in many applications, CQS, or a separate OLTP vs. Reporting models, are often not necessary.

I disagree with this and it shows a lack of understanding of CQS. I would recommend every system to apply CQS. At its root that is just a statement that you should have a separate layer for queries that builds DTOs off of projections as opposed to being built off of domain objects. There is no extra work to do or added complexity it is only different work in that you are putting the code somewhere else.

The idea of using a separate reporting model is allowed by CQS but it does not have to be used. In fact I would imagine most systems would not use but would instead be projecting their OLTP model, they will still end up with more control and a better overall system that they had projecting off their domain objects. If at some point later non-functional requirements dictate a need for a separate reporting model it can be introduced

Tricky Question

Greg — Fri, 24 Apr 2009 17:08:06 GMT

Someone gave me a tricky little question the other day that they had supposedly received in an interview at google and were stumped by. Its not really that tough but …

You have a circular queue of ordered items, come up with an algorithm for finding whether or not an item with the value of k is in it.

My first question: is the circular queue implemented as a list or within an array. Answer within an array (I was 1/2 expecting a problem to have to implement with a skip list for some reason).

A naive implementation would be to Iterate from head-tail end and then from beginning to tail, this will produce a result in O(n)

Can we do better? Spoiler below

We can do a binary search but it becomes a bit more tricky as things are not always sorted the way that we want. From above we know that if we have head or tail in a segment … the beginning of the segment to tail is sorted and we know that from head to the end of the segment is sorted. Coming though some other important examples.

Consider some examples when we go to split the data into 2 smaller arrays.

9 0 1 2 3 4 5 6 7 8
head = 1
tail = 0
3 4 5 6 7 8 9 0 1 2
head = 7
tail = 6

if head and tail are both on the same segment ... that side is not sorted properly

0 1 2 3 4 5 6 7 8 9
head = 0
tail = 9

If head is in one and tail is in the other then both are sorted perfectly.

If later we have neither head nor tail in our segments we know that they are sorted properly in their entirety.

By utilizing this information we can now trivially change our binary search algorithm to take into account the areas that may not be sorted correctly and issue a binary search!

Repository is Dead: Long Live Repository

Greg — Thu, 23 Apr 2009 14:28:41 GMT

The title sums up the argument in Oren’s recent post about repositories. Although we have had some discussions on twitter about that post I wanted to offer people a bit more of an analysis of what he has said and the pros/cons of such a strategy. His post was originally intended to be an “alternative to the repository pattern” which he believes “is dead”.

His new solution to the problem is to instead use query objects that are passed into the repository to remove the "complexity”. Of course this is far from a new idea in fact it has been discussed on this blog in Specification or Query Object and also in The Generic Repository where pretty much the exact same idea is put forward ( If you have not I strongly recommend reading The Generic Repository as it uses an almost identical method (except the query objects are used in the Repository implementation which composes a generic repository that it passes query objects to)). The concepts are also discussed in Domain Driven Design itself (they are just called specifications instead of query objects).

What is particularly annoying is the sensationalism associated with this post. It is extremely odd to argue against a pattern by suggesting to use the pattern eh? The suggested way to avoid the Repository pattern is to use the Repository pattern which shortening the definition he provided

Provides the domain collection semantics to a set of aggregate root objects.

So now that we have determined that he has not actually come up with anything new and is actually still using repositories let’s reframe the original argument into what it really is.

FindCustomer(id)
FindCustomerWithAddresses(id)
FindCustomerWith..

Oren has an issue with named query methods on a Repository interface. I will ignore the arguments provided by him and provide a simpler better argument for why you SHOULD NOT use these types of methods.

The Open Closed Principle. Versioning a Repository that uses these types of methods is extremely difficult. When I want to add a new method, or change an existing one I am changing the original contract. If I move these to a single method that takes a Query object I can change/add/remove queries without touching my Repository contract. In other words, we are simply applying SOLID to the repository interface.

Now we all know that following the Open Closed Principle amongst others is good right?

I would answer that question with “Yes in general following the SOLID principles leads to better Object Oriented code”.

I am sure I have left a few fairly confused at this point as I argue against my own point but I am leading to something important. The problem here is that the Repository interface is not necessarily Object Oriented. The Repository represents an architectural boundary, it is intended to be a LAYER/TIER boundary. Generally speaking when we define such interfaces we define them in a procedural manner (and with good cause).

Analyzing the situation given of a CustomerRepository what would happen if we were to want to put the data access behind a remote facade? With the simple procedural boundary of named methods, we would just go create a remote facade (say a webservice) and we would pass through the calls. What would happen though if we used the “other” Repository interface that is being suggested? Well our remote facade would need to support the passing of any criteria dynamically across its contract, this is generally considered bad contract design as we then will have great trouble figuring out and optimizing what our service actually does. With the explicit contract we have to explicitly add or change the contract and we know when things are being added that may need to be optimized. I am quite sure everyone has dealt at some point with the service that had 1 method and could do anything typically they take and receive strings my favorite are the ones you pass SQL to and they return you random XML (usually a serialized data table) …

One could argue against me here by saying that they don’t consider their Repositories to be LAYER/TIER boundaries… Well, I am sorry but you are using the pattern incorrectly then. If you don’t want a LAYER/TIER boundary don’t have one just use nhibernate directly … At this point you probably shouldn’t have a domain either though … If your system is complex enough to justify the cost of creating a good model why are you trying to optimize the < 2% spent on Repository abstractions?

After this Oren brings forth another very interesting issue that led him to his epiphany of killing Repositories.

It get worse when you have complex search criteria and complex fetch plan. Then you are stuck either creating a method per each combination that you use or generalizing that

I have had this smell in the past as well but instead of destroying the layering I am building into my domain (with good reason, see DDD by Evans for why) I went a completely different route. I noticed very quickly that it was by some random chance that my fetch plans were being different. I had a very distinct place where things were different, I needed very different fetching plans between when I was getting domain objects to perform a writing behaviour on them as opposed to when I was reading objects to say build a DTO.

This realization is what led me to command and query separation, the creation of a separate layer to process read->DTO transformations and to no longer use my domain repositories for this purpose. I should point out that for the read layer, what is being shown by Oren is a great way of implementing it. I won’t go into a large talk on command and query separation here (there is a good video from the european van and hopefully the QCon SF session will be up soon)… but if you apply command and query separation you will have almost none (read: none) read methods on your repositories in your domain.

Continuing along, Oren randomly puts forth the gem of:

A lot of people use it, mostly because of the DDD association. I am currently in the opinion that DDD should be approached with caution, since if you don’t actually need it (and have the prerequisites for it, such as business expert to work closely with or an app that can actually benefit from it), it is probably going to be more painful to try using DDD than without.

It being everyone has heard pretty much every real DDD practitioner saying this for years, I am really unsure why it has taken so long to figure this out? This also begs the question of what systems actually need or are suitable for DDD but that’s another day and another post.

Blog

Greg — Tue, 31 Mar 2009 04:37:07 GMT

Found a very interesting blog today.

http://jonathan-oliver.blogspot.com/

There is DDDD stuff here, some conjecture, some good analysis, some complete horse shit! but a LOT of interesting discussion! It will take me a while to read through it all.

My Horrible Lie

Greg — Thu, 19 Mar 2009 21:14:48 GMT

I have to admit that when I first started writing about DDDD I felt the need to separate its concepts from DDD. The reason for this is that the concepts being discussed were not in the mainstream of DDD. It needed to be segregated so that people could differentiate between the ideas....

Now to let everyone in on the secret. This was a deception on my part.

DDDD is DDD.

Today's VAN

Greg — Mon, 09 Feb 2009 16:26:00 GMT

As some may know the VAN last week was cancelled due to some technical difficulties. It will be happening this afternoon.

http://elegantcode.com/2009/02/02/european-virtual-altnet-meeting-rescheduled/ has the detailed information. I believe that all of the technical difficulties have been resolved as I now have a windows machine that can connect.