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.

Advertisements

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!

 

 

Hash codes and Equality in the .NET Framework

This is one of those topics that all developers use nearly every day without being often aware of. Now it’s quite rare that you need to deal with hash code and override Equals. The more you do object modeling (and domain modeling) the more you need it.

The .NET Framework strongly recommends that whenever you override Equals you also override GetHashCode. But why is it so?

Method Equals is always used when equality is checked explicitly such as when your code calls Equals directly or uses the == operator. GetHashCode is not involved in the equality assessment process. Subsequently, its implementation doesn’t impact the equality evaluation. Yet, you get a compiler warning if you override Equals but not GetHashCode.

GetHashCode comes into play only if your objects are going to be stored within hash tables or used as dictionary keys. In this case, the .NET Framework uses the value returned by GetHashCode to find the corresponding entry in the hash table or dictionary. Two object instances that are the same object according to Equals but return different values according to GetHashCode will never be considered equal. As a result, different values will be picked from the hash table or dictionary.

When your objects appear as public objects in a class library, you simply have no guarantee that they will never be used within hash tables or as dictionary keys. For this reason, it is strongly recommended that you override both methods to ensure that two objects that are equal according to Equals also return the same GetHashCode value. The returned value doesn’t matter as long as it’s the same. In light of this, why not simply making GetHashCode return a constant value in all cases?

When GetHashCode returns the same value for two objects you get a collision and Equals is called to ensure the objects are the same. A performance goal is of course minimizing the number of collisions giving each object with a unique combination of values a different hash code.

Finally, note that the hash code should never change during the lifetime of an object. For this to happen, only immutable properties should be used to calculate the code. This fits perfectly with guidelines for entities and value objects.

When DDD Leads to CRUD

As I progress on the second edition of bestselling Microsoft .NET: Architecting Applications for the Enterprise (NAA4E). I learn more and more about Domain-driven Design (DDD) and, above all, I’m seeing it through the lens of a different perspective. Instead of just blindly applying my understanding of it built on top of tips, tricks and advice collected here and there, I’m truly learning it from the foundation. And guess what? I can now fully answer the following (simple but tricky) question I got on LinkedIn. The question apparently is completely unrelated  to DDD. At a deeper look, though, it’s DDD that is related to nearly every aspect of software architecture; even when it could lead to a CRUD software.

For ASP.NET web applications requiring only CRUD operations(like automating paper forms), do you think using Entity Framework is slower than using DAL, BAL and presentation layer using stored procedures? Is using EF with stored procedure the right solution for this?

There are two distinct parts in DDD. You always need one; and may sometimes happily ignore the other.

1. DDD has an analytical part that sets an approach to express the top level architecture of the business domain in terms of bounded contexts.
2. DDD has a strategic part that relates to the definition of a supporting architecture for the identified bounded contexts. The default supporting architecture is Domain Model. A quickly emerging alternate option–in many ways fully replacing Domain Model–is CQRS.

The real added value of DDD lies in using the analytical part to identify bounded business contexts. This is the part of DDD that relies on the ubiquitous language–the key factor.

Once this has been done, the next problem is identifying the ideal way to tackle (read, implement) each bounded context. In doing so, you can certainly consider the two recommended supporting architectures of DDD. You can even–probably should–consider event sourcing in combination with CQRS.

But, in the end, it’s all about finding the ideal way to meet requirements in a well-understood business context.  So “ideal” should be measured against actual business requirements and NOT against ideal principles of code elegance, cleanliness, future extensibility, readability and the like. If, as in the question, all you need is CRUD and you need it quickly and probably don’t need it after a short amount of time, by all means go with a quick ASP.NET CRUD and stored procedures.

Stay tuned on Facebook for the progress of #NAA4E!

The Mobile Bubble that Kills and Resuscitates Apps

Taking cue from what my friend Davide Senatore wrote in a recent Facebook post, I want to share my perspective of mobile apps.

Even though I wrote a book on mobile architecture and mobile development jumpstart (iOS, Android, Windows Phone, PhoneGap) I haven’t done much work with mobile apps in the past year or so. I spent a couple of years a way back trying to make sense of the patterns and now I’m mostly acting as an advisor to some companies needing to build a mobile presence and elaborate a mobile strategy. My iOS developer account expired a few weeks ago and so it was for the Windows Phone account. Probably, both will be back some time soon but for the time being that’s it.

Two years ago I made the most significant experience with mobile apps. Two years ago the customer was really excited to have a few mobile apps to support the event. Last year the same customer kind of took it for granted and just looked for paying the update as little as possible; possibly nothing.  Every business has an app that, like web sites of fifteen years ago around the time of the Internet bubble, just do nothing serious.

People are led to think that most apps are just crap put there because of a trend.

As I see it, this means that the mobile bubble is approaching fast if not here already. Much like the Internet bubble didn’t kill the Internet, the mobile bubble won’t certainly kill the mobile. It will just put a few key things in the right business-oriented  perspective and get rid of anything else.

Mobile apps will die soon and some of them will resuscitate  later under another perspective.

Smoke-mirror apps created to let the world know ‘hey we have an app; download it to get a discount’ are all gone. Consumer apps are for the most part gone. Time-sensitive apps bound to events are for the most part gone.

What remains? Well, all of them.

Provided that the apps serve a specific purpose (WhatsApp, Twitter, Uber, Hailo, OneNote, games, a few personal utils apps, …)  or are the frontend of some significant enterprise system.

Don’t waste your time trying to create the next big app at all costs. Don’t expect that just any idea for an app (even good/great ideas) will make it a success or change the way people live and work. Don’t expect people will get it and rate it honestly. The true and sure frontier of mobile is where there’s a promising business case. But in this case the mobile app is merely the presentation layer.

JavaScript browser detection is here

If you’re good at googling you can find a few scripts out there that do the job of detecting the browser connecting to your site. To my knowledge, the best of these scripts can recognize whether it’s an iPhone or an iPad, an Android and little more. In summary, you can easily search for a few keywords and make some reasonable guesses.
Before you start jumping for joy thinking of how easy it could be let me add that knowing that it’s an Android is of not much help. Android what?

As you may know, it’s three years now that I’m part of the team that manages WURFL, the de facto standard of device detection. WURFL is a cross-platform API also available for ASP.NET via Nuget. Up until now, WURFL was only available for server-side detection. You can check my articles on MSDN Magazine for inspiration.

At the Mobile Congress today came the announcement that a client flavor of WURFL is also available for JavaScript. All you do is adding a short script to the page and receive a variable named WURFL that contains some basic information about the requesting device. The backend engine is the same of the cross-platform API. You can trust it 🙂

Here’s what you need to add to your pages:

<script src="http://wurfljs.com/wurfl.js"></script>

and here’s what you receive for Internet Explorer 11.

var WURFL = {
    "complete_device_name" : "generic web browser",
    "is_mobile"            : false,
    "form_factor"          : "Desktop"
};

The property complete_device_name returns the name of the device and it doesn’t go into much details for desktop browsers. The is_mobile property is a Boolean telling whether the agent is a mobile one. In my opinion this property is not much helpful. The real game changer is form_factor which returns string like “Desktop”, “Tablet”, “Smartphone”, “Robot”, “Smart-TV” and “Feature Phone” when it’s just a phone device but not that smart.

I set up a sample page for you to check the API: visit http://www.expoware.org/wurfljs. For more information, visit ScientiaMobile or contact me.