BYOT: Bring Your Own Tool in .NET vNEXT

I think it’s safe and sane to say that the pompously announced .NET vNext is–from a pure software perspective–just a minor update. At the same time, it is a huge change from a broader perspective that includes development strategies and the same Microsoft business model.

Frankly, I think that the “next” in the name refers more to Microsoft itself than the (ASP).NET platform. At the same time, though, just because it refers to Microsoft it is automatically of interest for all developers and shops active on the Microsoft stack. Nobody can afford ignore the vNext thing; and nobody should blindly jump on it just because at some point in 2015 it will be officially released.

One of the key changes I see in vNext–and it took me a bit of time and discussion to figure it out–is the support for development tools across a number of different platforms. In other words, you can now bring in your own set of favorite development tools (mostly editors) whether they run on a Windows, Ubuntu, or Mac system.

Does it really make sense–I wondered? Why should a developer drop Visual Studio to use a text editor on Mac or Ubuntu? That’s the point–a Microsoft developer probably won’t. At the same time, the BYOT approach opens the door to developers that just don’t use Microsoft products, are proud of their Mac, and won’t even consider running Windows though in a local or Azure VM. Thanks to excellent editors such as WebStorm and Sublime developers who wish can write for the next .NET (specifically, ASP.NET).

This is a huge thing. And the fact that I missed it entirely the first time I heard about it just … reinforces the point.

On the role of Responsive Web Design

Stuck in the Delta Lounge at JFK on the way back home, can you think of a better time to reflect on DevConnections sessions? As I get ready for reflection, I also feel the need to curse on Alitalia that doesn’t check me in online and requires me to walk through another layer of security to check in face to face on a code-share flight.

At DevConnections I held a workshop on building device-friendly websites and also gave a couple of sessions on the accidental relationships between DDD and Entity Framework and enhanced web input forms. I had a bit of discussion with attendees and other people of the role of RWD in the building of responsive sites. Here’s a summary of my workshop. By the way, the source code is here.

The workshop started with a critical review and analysis of RWD. It ended with attendees sincerely captured by WURFL.js–a free JavaScript endpoint that does transparent device detection and just puts in your DOM an object that tells about name and form-factor of the device, whether desktop browser, smartphone, tablet, smart-tv, watch, bot, or even a webview within a native app. I may seem like a guy who just hates RWD.

No, I just try to fight the blindfolded perspective that RWD is all you need and device detection is nefarious and the clear sign that you’re not doing a good job of designing and architecting your site. At the conference I also attended another talk on RWD and got illuminated when the speaker put an encyclopedic citation of an “expert” saying something along the lines of “we cannot have a single design for each application–we must upgrade to having a single design that works in all cases”.

Gotcha!

It’s that RWD stems from a designer’s–not developer’s–mind and vision. Developers, though, do a different job. Developers SHOULD be ready to focus on use-cases when they emerge out of requirements. Because devices exist and make a point of providing a unique experience, treating them as they’re all the same is against common sense. I grinned then when the speaker with a serious expression admitted that, yes, beyond aforementioned wonders, RWD does have the problem of performance. Really? OMG.

In the end, RWD is an excellent first-aid for setting up responsive sites. If experience is good, performance is good and nobody complains then all is good whether you used Bootstrap for it or your own combination of HTML5+CSS+JS. When you start getting complaints, then fixing RWD may really become expensive. Thinking that RWD can be applied tout-court and those who detect devices are a bunch of idiots who are not as smart as you is a plain distortion of the reality.

My workshop just showed the two faces of the coin. It showed facts and numbers (rather than astonishing demos) and left conclusions to developers.

NAA4E Kindle edition is out!

After a long labour it finally delivered! At last, at least the Kindle edition of Microsoft .NET: Architecting Applications for the Enterprise (NAA4E) is out available for download. The book has 14 chapters two of which should be made available for free at some point in the coming weeks. Free chapters are “Discovering the Domain Architecture” and “Introducing CQRS”.

All in all, they are the two most relevant–because most inspiring chapters of the entire book. If there’s one primary purpose this book serves that is the purpose of separating the idea of DDD as an approach to development from the idea of  having a domain object model. The two things are fused together in the Eric Evans “blue book” but the  same author revisited the perspective in a later session back in 2009. For what we can say, the majority of developers missed this point. We say that DDD as a guideline is key to everybody and every project; the domain model (entities, aggregates, value objects) is just one of the many supporting architectures. CQRS is yet another supporting architecture and comes up just to fix the open/weak points of Domain Model. Enjoy! And stay tuned with latest news on Facebook. Like us at facebook.com/naa4e.

Source code of the book is http://naa4e.codeplex.com.

TechEd Europe sessions

Andrea Saltarello and I are slated  for two breakout sessions this fall at MS TechEd Europe. In addition, I’m going to run a workshop on Monday October 27. More details here.

Architecting and Implementing Domain-Driven Design Patterns with .NET

Domain-driven Design (DDD) is an approach to software design and development that focuses on the analysis of the business domain and uses ad hoc tools such as the ubiquitous language to split the business domain into distinct subdomains, each of which becomes a bounded context and requires its own architectural approach. After a brief introduction on the foundation of the DDD approach (mostly ubiquitous language and bounded contexts), we’ll focus on a reference .NET application and discuss its implementation of the Domain Model pattern (aggregates, POCO domain entities, value objects, domain services) while contrasting the use of anemic domain models. Next, we’ll compare the Domain Model implementation to the CQRS pattern. In a CQRS architecture, the business logic of the application is expressed in terms of command and events and queries take place on a physically segregated stack. Along the way, we emphasize the role and structure of the persistence layer and touch on cross-cutting concerns (scalability, caching, security) and dependency injection to protect domain logic from infrastructure technologies. Overall, this session presents the state-of-the-art for enterprise application architecture and development in .NET. By attending this session, you’ll get a global vision of the fundamental DDD patterns and see them implemented in reference application.

 

Applying CQRS and Event Sourcing in .NET Applications

When you use the Event Sourcing pattern in a .NET application, your data source just consists of persisted events. You don’t likely have a classic relational data store; all you store are events, and you store them sequentially as they occur in the domain. As you can guess, persisting events instead of a domain model has a significant impact on the way you organize the back end of the system. Event persistence weds well with a strategy of separating the command and query stacks (CQRS), and with the idea that distinct databases are used to save the state of the application and expose it to the presentation layer. When you add ES to a system, you just change the structure and implementation of the data source. In this talk, we just develop a mini-ERP application that works out of distinct command and query stacks and persists just events. We also discuss how to rebuild state from events and see when replaying events is an option and when you’d better use up-to-date or partial data snapshots. Overall, this session presents a concrete example of a cutting-edge application architecture that for its inherent simplicity and maintainability is gaining momentum whether you have a complex business scenario to scale out or a just a CRUD system a bit more sophisticated than plain CRUD.

See you there! And check out related book at facebook.com/naa4e. By the way, why don’t you like the page? 🙂

TechEd Europe 2014: CQRS and the Egg of Columbus

According to Wikipedia, the expression “egg of Columbus” refers to a brilliant idea that seems so simple and obvious after the fact. The same idea that at some point seems doable by everybody was out of reach before someone actually did it.

CQRS is the latest egg of Columbus in software architecture. Once smart people like Bertrand Meyer, Martin Fowler, Greg Young, Udi Dahan  had formalized it at different times and through different steps, it sounds like it is such an easy thing that nobody needs credits for that. As I see things, one of the reasons why CQRS doesn’t sound so exoteric as DDD is that it is really simple and effective to the point that is seems to be a natural element of software development.

CQRS in a way fights the idea that it is always necessary build a complex and convoluted domain model that encompasses all possible actions within a given domain. CQRS applies an old strategy that rulers of the past used extensively: Divide-et-Impera. It does that by splitting commands from queries and inviting architects to design both through distinct stacks. Stacks are distinct in all regards–technology as well as patterns.

This year, I’ll have a full-day precon workshop at Microsoft TechEd Europe in Barcelona (Monday, October 27) just dedicated to .NET architecture. The title is “Architecting .NET Solutions for the Enterprise” and it lays the ground for a CQRS-inspired design and implementation starting from a deeper analysis of DDD. You’ll see a reference application–an online store–first  designed and implemented as a canonical DDD project. Next, you’ll see the same application rebuilt using commands, events and queries as distinct stacks. Here’s the list of modules:

• Discovering the Domain Architecture: ubiquitous language and context mapping.
• The Domain Model Supporting Architecture: essentials of the Domain Model pattern and role and structure of the domain layer in a multi-layer architecture.
• The CQRS Supporting Architecture: task-based implementation in the command stack and plain LINQ-to-Entities queries in the query stack.
• Event Sourcing: storage of events instead of working out a full-fledged domain model and persisting it through an O/RM.
• UX-First Design: the key message of this workshop is that today the UX is the most important aspect of any software. Focusing on UX leads to understanding clearly and unambiguously the tasks the application must perform.

Most of the content of the workshop is inspired by the freshly released 2nd edition of the NAA4E book “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014) that I authored hands down with Andrea Saltarello. To stay in touch, have a look at our Facebook page.

PS: By the way, we’ll be releasing the reference applications in the book (and discussed in the workshop) on Codeplex sometime soon!