you are totally right stating this principle. but you are totally wrong when you say that NSK are solving a simple problem with a complex solution. NSK is a sample base that illustrates a possible implementation of a complex problem, not a simple one. maybe you can question that northwind is not the smartest db schema to base that implementation, we can debate about that. but I really don't understand why you go on saying something simply not true even if many people told you you are missing the point with NSK. and believe me, you are still missing the point.

Sincerely.

"If you are demonstrating how to solve a simple problem in a complex way, you are basically doing disservice to the reader."

I've found this often, looking for implementations of different patterns to see how it would be implemented, but it's always hidden away in a billion layers or 100's of other patterns that it makes it hard to figure out how it's implemented to begin with.

Hi Ayende, this is Andrea, the "main author" of NSK. I'm pretty interested in understanding why are you saying that "it seems that your post did offend me", since I've neither commented your post nor posted my thoughts on twitter/facebook/blog/whatever-platform-you-like-most

TIA.

Just the final note. You speak about context, perfect. Do you know the NSK context? do you know where it comes from? all the conferences and workshops that are behind NSK? the MS Press book? all the discussions around NSK in his 5-6 years history? if the answer is yes, great, I will read your 9 post series about NSK. if the answer is no, or just a few, i suggest you to get the full context of NSK before starting to write something based on the wrong context. Context is King, doesn't it?

Hi Ayende. How do you propose software architecture for complex projects should be taught? Should it be taught without examples?

Hm. Guess I meant teached.

@Roberto: "NSK is a sample base that illustrates a possible implementation of a complex problem, not a simple one." What exactly is complex about the problem that NSK is supposed to illustrate? It just looks like a bog standard CRUD app to me.

The project's home page specifically says "The Northwind Starter Kit is ... intended to be used as a blueprint when designing and implementing a .NET layered application architecture." It also makes no mention whatsoever of any MS Press book nor of any discussions around it in its 5-6 year history. All I can see here (without wasting time clicking through numerous links to try and find anything different) is an invitation to newbies to cargo cult exactly the same architecture into their own projects, regardless of whether it is warranted or not.

I'm with Ayende all the way on this one. Over-complexity and unnecessary layers of abstraction are dangerous.

James, you are right, we can say that the home page missed some information, everything could be improved with the right advice. but in the previous post there are plenty of comments that illustrate the context of NSK: the MS Press Book, something about its long history, something about the fact that it's not a "simple" CRUD application (oh my... did you dig into the code?) those comments are sufficient imho to stop a moment and ask for a better understanding of the whole project, why it's there, what it really means, why Northwind was choosen. with NSK here in Italy we grow up around DDD in the last 5 years of workshops, conferences, discussions, trying to dig into architecture not just for the sake of personal delight, but for the sake of knowledge. Out there there are a lot of prittle-prattle about DDD, but not a single line of code. we ask ourselves what really is a domain context, a repository, an aggregate, a domain model, a domain entity, a value object, a service layer. Andrea tried to explain them in many different ways (as I said workshops, conferences, a book with Dino Esposito, and so on), but as a dev he wanted to show also some code, because our job is to write code, not to chat about something abstract with a microphone. this is the context, and if you think it's not well documented, it's perfectly OK to tell us to improve our communication, but if you are measuring the complexity of the solution proposed simply counting the number of projects, or simply labeling the application as a banal CRUD thing, let me say that you are doing a big big mistake. and I still think you are too smart to make this mistake.

Ayende, the point is in the "real need". the DDD book comes with a subtitle "taking complexity into account". the whole book design a possible solution that is really complex, because all the single parts of DDD are really complex. NSK is something that presents a possible solution when you have to face something really complex in your real life. it's too simple to say that in real life there's no northwind db schema, but the real question we asked ourselves is: what if we, someday, will be asked to solve a really complex scenario in which there are complex business rules, multiple user contexts on the same business entities and stuffs like theese? if thay tried to think a real world complex scenario to implement, NSK would never see the light of the sun, it would be totally impratical. did you take into account this kind of instances? because in this moment I can only think that you have a totally different vision about DDD, a vision in which really complex scenarios are solved in a very simpler way. and mind that if you will try to downgrade the scenario to a normal CRUD one, yes, you will totally miss the point around NSK. and believe me, we are the first one (me in particular) that will never design a solution in the NSK way facing an average complex scenario.

perfect Ayende, now i got your point, and I can understand your vision about NSK. let me only say that "And yes, if you want to demonstrate DDD effectively, you ARE going to need a complex problem set" imho is not the best attitude in teaching something. maybe it could be great for smart people like you, but in the average, as I learnt at university, complex problems are first solved with a small model in a laboratory. all the great hydraulic italians build all over the world started with a spike in a laboratory. many times you simply cannot start from a complex problem. I will read your series about NSK with this in mind and I'll try to get the net weight.

Ayende, I totally disagree, not only in the IT context. my engineering education tells me that you are wrong, but I think now we are discussing something that is not technical anymore, something that comes from our past experiences, school education, attitudes, cultures etc.. it's a bigger and delicate scenario, and I don't think this is the right place to face it.

I think you're off base Ayende.

I already have enough complex problems at my job. I know what the complex problems are.

What I need is clear demonstrations of solutions.

Despite what the internet think, not all newbies are dumb automatons. Some of us have the ability to decide whether a demonstrated solution is a good fit for our own complex problem.

So when I read something like NSK I can imagine what it would be like solving my own problems. I don't need a huge sample project - I already have my own. I need clear demonstrations of things like: "Here's how you build a service layer in .NET".

Personally I found your Macto posts very boring and I stopped reading them. Why do I want to read about a prison problems? I already have plenty of complex problems at my job to worry about.

Sure, if your review said "This is the wrong way to build a service layer; here's how you should do it", then that is something I would be interested in. Or even if you said, "You don't need a service layer at all", well that's fine, but I happen to know that I need -something- because currently what I have is far too messy. So unless you can explain a good alternative solution its highly likely that you are just going to sound like you are just trolling.

I still maintain that a simple project can warrant an architecture that on the surface, may seem overly complex. Sometimes a simple CRUD application can evolve over time (possibly years and after several releases) into a higly complex system. You may know this from the start, either because you have been forewarned, or because you are familliar with the client. A more complex architecture may make an application more maintainable - the new functionality can simply be slotted into the architecture. However, if you have a very crude architecture, you may find you have a lot of rewriting to do. Either that or fudge it in and watch the code rot set in.

@Paul: It's all very well saying that, but there are numerous different ways in which you can add complexity to your project, all with different benefits and trade-offs, and you're all too likely to end up introducing the wrong one.

For example, a generic repository can allow you to swap your SQL Server database for RavenDB relatively easily, but at the expense of making tight performance optimisations all but impossible.

Besides, if you never need to make use of that complexity, you're just hamstrung with extra friction on a day-to-day basis.

Maybe the main point is that DDD, CQRS, TDD and all other religions are meaningless. You can't do anything with them that you couldn't do using plain SQL and c# or even a bash script, without introducing all this babbling and complexity nobody cares to understand. If the rules were clear there wouldn't be a need to provide counless guides and best practices that contradict each other.

@Rafal - Normally when Ayende posts about all things wrong with a project I usually disagree with him. But after taking a look at NSK after he posted it, I personally find it far too complex and difficult to learn from.

It's not like it took the NW DB and used it as a base to show the repository pattern OR used it as a base to show DDD, OR used it as a base to show insert pattern...

I think some of the best examples of showing something off, are the examples that ship with NServiceBus. Because it was dead simple to open one of those up for WCF or WebForms and see how it works, etc.

^ IMO.

I'm kind of on the fence here. On one hand, I agree with Ayende that needless complexity is a bad thing. On the other, I am a proponent if doing proper design for any non-trivial application, whether it be pure CRUD or not. In that regards NSK is a decent approach to show how to take the typical business app (like it or not I would argue that the majority of line-of-business applications are structured a lot more like Northwind than, say, AdventureWorks) and separate it into the correct layers for future maintainability.

Does the sample go too far? Probably; I haven't looked at it outside of Ayende's reviews so can't comment on that, but having a Repository layer (even if it's more like Table Data Gateway than the DDD Repository), a services layer, and the like are more often than not a good thing - at any rate it sure beats the typical .NET approach of tossing everything in a code-behind of some ASPX file!

Also, please revisit Macto Ayende! :)

There is a difference between "proper design" and "overdesign."

I'd say Ayende is spot on about this.

Every example I ever read on using an IoC container took a simple problem and made it WAY more complicated.

They all tried to explain it away saying they needed a simple example, but the result was I avoided using an IoC container for MUCH too long because of the over complicated simple examples.

When a co-worker showed me a complicated example made simpler by IoC containers it immediately clicked.

So I'm with Ayende, if you are showing a complex solution, show a complex problem to go with it.

Otherwise, you are leading folks astray...

Ayende, I used to be a development manager and as a result I've heard MANY developers say something along the lines of "why did <Person X> make this so complicated? It should be nice and simple!" Then when Person X reimplements it himself, two months later he delivers code of exactly similar complexity. Then I say, "See, it wasn't so simple after all."

The truth of the matter is that everything looks simple until you actually try to do it. In fact, making things simple is so difficult that we typically remember those people by name ... Albert Einstein, Steve Jobs, etc. I should also say that making things simple tends to be extremely time consuming.

So, before we pass judgement on the Northwind sample or your feelings about it, I would encourage you to show us your version of the Northwind sample (with the same level of functionality, of course), so we can compare and contrast effectively.

Ayende, I took a long time on that code... :( ...please show us a detailed review

thanks

I still don't understand why people still consider the repository pattern good for complex applications. It took me working on one real-life project to immediately come up to it's major flaws (performance, bloat, and over-complication) and make me realize not to use it. And generic repositories are even worse.

Matthew: Software development is an evolution of lessons learned.

@Matthew You've discovered yourself that The Path Of A Real Programmer is not about following someone else's advice and using someone else's tools. You have to have your own tools and techniques and if a tool is missing then create it. And remember Real Programmers don't have time for showing off, writing blogs or tutorials and bragging about their awesomeness.

I'd still rather have a 9 article series showing how you would do things "better" than a 9 article series on how they are doing it wrong.

If you're going to invest the time, make it productive.

Amen.

Love the art analogy. I think one of the things I like about OOP/DDD is that I find them aesthetically pleasing. I guess it's easy to mistake pretty code for appropriate code.

Funny! Looks like everyone forget that both NSK and ayende.com are marketing tools...

On the matter, I agree with Ayende (in particular becouse it's impossible to teach anything about DDD while facing with CRUD requirements like the Northwind ones), but I don't think that any serious developer requires such detailed, boring reviews (to juniors ones they could be useful, however).

Still, why do you care so much? It's just an opinion! And btw, we are not our code... when we like it too much, it's just becouse we haven't learn enough.

@Giacomo: So it's "just an opinion" that you should write your code in a way that's easy to maintain??? In that case is it "just an opinion" that magic numbers are bad, that meaningless method names such as "do_it" are bad, that 2000-line, 80-parameter stored procedures are bad, and that copy-and-paste code is bad?

Here are some questions for any of you who think that NSK-style architecture is acceptable. How many places in the code do you have to change if you want to add a column to the Orders table? How long does it take you, as a developer unfamiliar with the codebase, to find them all? How confident are you that you haven't missed any? How far apart in the solution explorer are they? And how long does it take you to verify the change?

@James: the fact that I agree with you (or Ayende), doesn't means that we have any truth. ;-)

note the difference between modern and contemporary art, the former finished 40+ years old, before a lot of us were born.