Teach yourself DDD in 15 minutes

DDD or Domain Driven Design is one of the most difficult thing to learn. Entire libraries have been written about the subject, and many senior developers have spent decades trying to learn it, often unsuccessfully may I add. Its elusiveness for software architectures, sometimes feels almost like the equivalent of searching for the grail. At the same time, it’s considered the most important concept to know for a software architecture to be considered a senior architect among his peers. However, if you simplify DDD, and create generalisations around its ideas, it’s actually pretty simple to understand.

I have created a Micro Framework for ASP.NET Core web APIs that allows you to browse its 400 lines of code in 20 minutes, and afterwards actually have not only a pretty strong grip upon DDD, but also your own tool to start using DDD in your own solutions. In essence, it’s a starter kit for ASP.NET Core web API development, that creates a template for you, that makes sure you’re following all best practices if you follow a simple recipe as you create your own web APIs.

The basic ideas are DRY, DRY and DRY – As in “Don’t Repeat Yourself”. By following this axiom as deep into the Rabbit Hole as possible, you end up with a framework, that allows you to create your C# apps, literally without coding almost at all.

Check it out for yourself here

Advertisements

Agile software development is all about the tools

The above statement, is the equivalent of putting my foot into my mouth, and committing social software suicide. The reason is that the Agile manifesto, repeatsĀ “Agile is not about the tools”, in literally every single paragraph. So when I claim what I do in the header of this article, I literally disagree with every single software development theory, that has ever been put forth – And every single software architect guru, that has walked this Earth in recent times. However, I can prove that I am right, and I intend to do so in this article.

At the heart of “being Agile”, is the ability to be customer driven. This implies that the customer is allowed to make all the important decisions of what features the end software should have. In fact, this is the sole motivation for why system developers seeks to become “more Agile”. When the customer gets to decide how the end product ends up, the software is able to reach its goals. When the customer is not able to influence the end result, we might just as well start flipping burgers, since we don’t provide the expected value for our customers – And our customers will end up leaving us, and go to somebody who is able to deliver what the customer actually wants.

If you wanted to buy a car, and the seller gives you a horse, how would you feel?

The above is such a self evident fact, that arguing about it, is meaningless. If you create a statue out of granite, then once it starts taking shape, there is no way to really modify it. If you instead start out with building blocks, or “clay” to use an analogy – You can always go back and change it. Hence arguably, we have already proven that “Dynamic programming languages is a better tool for being Agile than statically compiled languages, and since programming languages are tools, well, you get the point” …

The Agile manifesto, and its different methodologies, seeks to “facilitate for change”, by creating all sorts of theories and methodologies about how to manage your code. For instance, eXtreme Programming taught us that we need Unit Tests, since this allows us to change our code, without introducing bugs. The objective of course, is to change your system. The Unit Tests from this perspective, is simply a tool, that allows you to safely apply your change.

Hence, arguably, we have already implied that XP is all about the tools

However, we can bring this much further. Imagine a system, where its core developer only creates the core building blocks, and the process of tying these together, is left for the customer – Under guidance from the main developer of course. Such systems facilitates for becoming Agile, to an extent impossible to imagine for most system developers. Then imagine a system where its core developer, can apply most changes, faster than the customer can communicate these changes – Facilitating for that its core developer(s) can modify the system, in a conversation with the customer, showing the results of the customers needs, seconds after they have been communicated? Would that be “Agile”?

Well, let me show you a tool which facilitates for that.

Then come back to me and argue that “Agile is not about the tools”

Facts are, Agile is only about the tools. And the better tools you start out with, the more Agile you allow yourself to be. And the more Agile you allow yourself to be, the more happy customers you will have. And the more happier customers you have, the more happy you will become, and so on …

Agile is all about the tools!

Magic menu is a new way of communicating between computers and human beings, allowing humans to rapidly “configure” what they want the computer to do, once some “button” or “menu item” has been selected. Read the following article, and try to explain to me how the Magic menu is not a tool, and how it does not facilitate for becoming more Agile – And I will eat the foot that is now in my mouth, if you can …