Little Architecture Huddle

Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid - all rolled into one format.

This is the book I'm currently reading

And? (Quite funny. I was just going through the InfoQ newsletter myself :)

Actually a really good book. Very different topic, more focused on configuration, deployment and operational stuff and not really code.

"Udi and I agree on probably 95% of what we talk about, one of the places that we have differing opinions is in the use of Event Sourcing I use the term as described previously to mean the rebuilding of objects based on events, not the definition that is currently on the bliki. To me this is an important distinction and I figured it would be worthwhile to write a post on why I feel the way I do, I explained parts of it in the previous post about CQRS and Event Sourcing but I wanted to talk not just about how the patterns are symbiotic but also some of the other reasons I use event sourcing."

"A few months ago, Jimmy Bogard, author of the excellent AutoMapper wrote a great article about Autoprojecting LINQ queries. Now that Jimmy has done all the hard expression tree work, this article extends his example to include caching and simple flattening capabilities and goes on to show it in use in a simple EF 4.1 Code First application."

Some very interesting metrics on checking code quality - I like this!

That dev team must be very motivated and must be doing really great work!

"Just Enough Software Architecture book, by author George Fairbanks, focuses on a risk-driven approach to software architecture development. RelatedVendorContent Got fires in production? Find root cause in minutes. FREE Java performance tool The Agile Business Analyst Experience Java EE! 600 page Redbook Testing Platforms Analyst Comparison: IBM, Microsoft, Coverity, MKS, and more Transform IT Complexity to Achieve IT System Vitality George explains the Architecture Modeling process from different perspectives such as Engineering Use Models, Conceptual Model, Domain Model, Design Model and the Code Model. He also discusses the various architecture styles including Big ball of mud, Pipe-and-filter, Batch-sequential, Map-Reduce and talks about the distinction between architectural patterns and architectural styles. The discussion also includes topics like evolutionary design, architecture refactoring and how to analyze, test and validate the architecture models."

Sounds like this guy is confuse between enterprise architecture and solutions architecture. Or I am. :)

I think both those roles are evolving quite quickly at the moment. The classic Enterprise Architect is having to find new ways to plan, communicate and check quality as more and more teams explore Agile methodologies. The Solution Architect is suddenly playing a more obvious role as a result of the above. My feeling is, it is not so much about people, but about function. The same person could operate as a Solutions Architect most of the day, but then could get together in some kind of Architect's forum and play the role of an Enterprise Architect. That forum then wrestles through the Enterprise Architect issues and establishes the back-bone on which the Agile Development is done. That's what is probably happening, formally or informally in a lot of dev teams at the moment.

"It looks like that CQRS has finally "made it" as a full blown "best practice". Please accept my apologies for my part in the overly-complex software being created because of it."

" Performance is a topic of increasing importance in the software industry. Today performance engineers and architects as well as operations people have to ensure that complex application landscapes works seemlessly and problems are resolved fast and with minimal effort. "

"In many conversations, and in many comments here, you hear phrases like "well that's not really suited to DDD" or "DDD isn't the best fit for that problem". You even see those kind of comments on my blog, and often they are posted by me."

" Ulf Wiger advocates for a programming model change based on the actor model which more accurately reflects old human concurrency patterns that we have used in our daily lives for thousands of years. "

"I'm passionate about Domain Driven Design (DDD). Like many experienced object modellers, I was practicing this long before Eric Evans coined that specific term, though I have sinced learned some useful specific patterns from his book. To me, DDD is about two things: focussing on the business functionality rather than on the technical implementation; and focussing on building a good model of the business domain rather than just on the specific immediate requirements. Like many others, I perceived that the key to this was to model the domain as behaviourally-complete domain objects: to actively resist the tendency to separate business functionality from the persistent domain entities."

"IDEAL CHALK mnemonic acronym and mnemonic images for Object Oriented Principles"

"This site has been setup to replace the creaking and aging site at dddstepbystep.com, which for all it's plus points, was proving impossible to maintain. Sorry Community Server you had to go!"

Book is now available in PDF form for free

"Modern business relies on multitasking to get work done. Employees are evaluated on their ability to multitask. IT professionals are routinely assigned to multiple projects. Did we always do this? Does multitasking work? What are the real impacts of multitasking? Is there an alternative?"

"If you're in software development, new techniques, languages and concepts pop up all of the time. We all feel those nagging doubts every now and then: "can I keep up with the changes and stay competitive?" Take a moment, and sum a line from my favourite movie, Casablanca: "The fundamental things apply, as time goes by.""

"Kanban represents a unique way of catalyzing the application of Lean product development principles to software development, maintenance and operations. Being a method for driving change Kanban does not prescribe specific roles, practices or ceremonies but instead offers a series of principles to optimize value and flow in your software delivery system. As such, Kanban's focus on context and adaptability has made it increasingly popular for teams working in contexts where traditional Agile methods are not an easy fit and mature Agile teams looking for ways to further optimize their development process."

"As a change agent, you constantly need to reassure people that the path we follow is worthwhile traveling. This need is often expressed in the form of critique and difficult questions. When I coach Agile teams, this is often the case. The same thing happens when introducing Kanban. However, I noticed that Kanban raises much harder questions on a management and leadership level, once people are introduced to the basics and start to explore the subject on their own. For instance: "How can we plan if we measure instead of estimate?""