Domain Driven Design (DDD) & Visual Studio 11 Beta ALM, great fit!
 |
|
ALM |
Domain Driven Design (DDD) is especially suitable for creating long-term LOB Apps, but usually, DDD is presented as a very patterns & architecture related subject (topics like Bounded-Contexts, Domain-Models, patterns like Repository, Aggregate, Value-Object, etc.), like we actually did in our ‘DDD Patterns Guidance with .NET’, but those are not, in fact, the most important topics when really applying DDD.
Domain Driven Design is much more than Architecture and Design Patterns. It implies a specific way of working for development teams and their relationship with Domain Experts, a good identification of Domain Model elements based on the Ubiquitous Language (specific vocabulary, terms, etc.) coming from the Domain Experts, stakeholders and users, for every Domain-Model we can have. All those topics are more related to the Application Life-cycle Management process (ALM).
DDD is a way to build apps, a way for the team, to work in projects. According to DDD, the project’s team should work in a specific way, should have direct communication with the Domain Experts (the customer or users, in many cases). The team should use an ‘Ubiquitous Language’ projected up to the the code itself (entity names, object names, etc.) which has to be the same language/terms used by the domain experts and users.
Whenever I say ‘Domain Expert’ (DDD terminology) I also mean, for most applications, ‘Customer’, ‘Stakeholder’, ‘Product Owner/Manager’ or even ‘User’.
The following diagram shows the typical DDD Application Life Cycle:
Like mentioned, because DDD requires a direct communication & collaboration between the Domain Experts (users) & the development team (and I mean direct communication flowing from the Domain Experts to the developers themselves, not through any ‘man-in-the-middle’ figure), we need to enable developers and domain experts to work together more closely.
In most development life cycles, the requirements and changes coming from the Domain Experts are often misunderstood caused by the differences between the lay vocabulary of the users (Ubiquitous Language of the Domain experts) and the technical vocabulary of the analysts and developers.
Additionally, as you can tell from the DDD Application Life Cycle diagram, DDD is complementary with most Agile methodologies, like SCRUM.
In DDD but also in most agile methodologies, we seek to address and accommodate change, we ‘embrace the change’ coming from the customer. But, the basic problem remains: Users & Domain-Experts must be able to express their requirements in a clear, concise and unambiguous manner that can be understood by the developers.
Including Domain-Experts & Customers in the Development workflow
A key part of successful application development is to listen to what Domain-Experts & customers say and to build what
they really want. To assist with understanding and documenting users’ requirements, Visual Studio 11
Beta provides Storyboarding tools. These tools enable the development team to discuss and visualize
requirements with users and to understand how users expect to use the application. The storyboard can be
saved to Microsoft SharePoint and linked to Visual Studio Team Foundation Server 11 Beta work items to
help provide context for the developers.
In DDD and in most Agile environments, developers must be able to quickly demonstrate the results of their labors and
obtain feedback from Domain Experts and users, again in a clear, concise, and unambiguous manner. Visual Studio 11 Beta
provides tools (like Feedback Manager Tool) that enable a stakeholder (like a Domain-Expert) to review the software and provide actionable feedback. The team can generate the appropriate tasks to deal with this feedback, plan for their implementation, and allocate the corresponding work to the appropriate members of the team. The feedback is stored in the Visual Studio Team Foundation Server 11 Beta database and is available to the developers who are responsible for incorporating any required changes.
Below is shown the working process and collaboration between the Domain-Experts (stake holders, users & customers) and the development team:
Gathering Domain-Experts requirements
The first step when getting the story from the Domain-Experts is gathering the requirements and explanations of the Domain. For that purpose it is very useful to have toolsets to visualize ideas and draw story-boards.
The Storyboarding Tool is an add-in for PowerPoint that enables a developer to work with a Domain-Expert in order to understand the business requirements and to plan how the application should function. With this tool, you can quickly mock-up a user interface and create animations that illustrate how the user expects to navigate through the application, show sample data, simulate events, and generally get a feel for what the user wants.
StoryBoarding Tool
The Domain-Experts and users simply use PowerPoint to view it.
The Storyboarding Tool provides a rich library of controls, but you can also create custom shapes, import them into the storyboard shape library, and share them with the rest of the team.
Gathering Domain-Experts and Customer Feedback
Your customers and end users are the reason that you build software. Therefore, obtaining their feedback, and feedback from the Domain-Experts, is critical to the success of the project. Visual Studio 11 Beta provides the Feedback Manager tool, which enables these key Domain-Experts and stakeholders to provide timely and actionable feedback to the development team. Actionable feedback includes not just text comments but also videos, screenshots, and audio annotations that help the user to highlight any specific issues. These items help the developer to understand the context in which the user was performing the actions when a problem occurred or a feature
was found to work incorrectly.
Using the Feedback Manager, the user can run the application and record the ways in which the application is used. The user can also take screenshots or record audio and video at any point, perhaps providing a running narrative of the tasks that he is performing.
|
 |
The Feedback Manager records the user’s interactions with your application and logs keystrokes, mouse clicks, and
other events. When the user has finished the feedback session, clicking Submit saves the feedback information to
the Visual Studio Team Foundation Server 11 Beta database. The user also can provide a rating and comments for the application.
Managing the Life Cycle of long term Applications
Domain Driven Design is not suitable for any kind of applications. For instance, Data-Driven Apps, or static and short-term apps should not be built using DDD. It would be like building a bicycle using rocket science/technology. The DDD learning curve, patterns complexity, loosely-coupled components and and its carefully Domain oriented way of working wouldn’t make sense for simple and short-term apps.
On the other hand, DDD is suitable for long-term apps which have quite a lot of business logic, but, where its business logic is always evolving. Typical DDD apps have “ever-changing business rules”. And then, whenever we have an application where it is always changing and evolving, we will have many application versions to deploy during its life (possibly, during quite a few years). For this cases, a right Operations framework and life cycle management is critical.
DDD applications (or specific Bounded-Contexts) are typically a living asset, with a life cycle that spans the activities that represent the entire lifetime of the product, from identification of business requirements, through development, testing, deployment, support, and maintenance, right up to the eventual retirement of the application.
If we have many versions to deploy along the time (Typical DDD long-term apps), each time we deploy a newer version in the PRODUCTION environment, we are not only introducing new functionality, it is quite possible that we will be introducing new bugs to be detected and fixed. As the software is used, bugs are often discovered. So the toolset must provide facilities for recording issues, to enable the development team to resolve them, and to provide the operations staff with the information that they require to roll out the fixes. This interaction implies an inherent connection between the processes that the development team performs when it builds and maintains the software and those that the operations team uses to manage the software when it is deployed. Development and operations personnel must be able to collaborate effectively because there is potential for bottlenecks to occur that will lead to delays and inefficiency wherever handoffs between the two teams exist, especially when there is scope for miscommunication between them.
Development / Operations collaboration
Visual Studio 11 Beta helps to align development with operations into a seamless workflow, reducing the churn that can occur. For example, a common situation is that the operations team reports a bug in the live software that the development team is unable to reproduce outside the production environment. To help with situations such as this, Microsoft IntelliTrace has been extended to support the production environment. By using Visual Studio Team Foundation Server 11 Beta, the operations team can record and capture the sequence of events that caused the bug in the Production environment and to store the trace information, together with the appropriate production environmental data. The operations team can then hand this information, together with any other observations, to the development team for analysis and triage. Following an Agile approach, the project manager can subsequently create an appropriate work item and allocate it to a developer. This workflow helps to accelerate communications between the development and operations teams, ensuring that bugs are resolved and updated software is deployed in a timely manner.
IntelliTrace in production is an historical debugging tool that records the sequence of events that led to the unexpected behavior. The information that IntelliTrace captures includes diagnostic data, details of exceptions, the call stack, and a trace of where the code failed. The data that IntelliTrace captures can be stored and then replayed by a member of the development team by using Visual Studio 11 Beta. A developer with Visual Studio 11 Beta can use this information to debug the application as if it was running live on their development computer.
IntelliTrace in Production
Working Closely with Operations Personnel
Visual Studio provides a server monitoring solution for teams that use or want to adopt System Center Operations Manager (SCOM). Visual Studio can deploy a monitoring agent for ASP.NET applications running on a web server. This agent collects rich data about exceptions, performance issues, and other errors. Using the TFS Connector for SCOM, Operations staff can file these exceptions as work items in TFS and assign them to developers to investigate in order to improve and fix production web applications. Visual Studio and the TFS connector, in conjunction with SCOM, provide a real-time improvement feedback loop for server-based applications deployed in production, leading to continuous improvements and high quality.
Closing the loop with Operations Personnel, System Center Operations Manager (SCOM) and TFS
Summary
Domain Driven Design is not only related to architecture and design patterns. In order to really apply the DDD approach, it is fundamental to take care of the direct relationship between Domain Experts and the development team as well as the relationship between production operations and the development team. Visual Studio 11 provides useful tools for that.
Light
Dark
0 comments