Whither Microsoft .Net in next gen platform

There’s a valid question to be asked around the technology platform and direction for a rebuild of the eCommerce platform.  Historically, we’ve been a Microsoft Asp.Net based shop; outside the team there’s something of a perception that we’re tied to Microsoft as a development  and deployment platform.

Some of that perception stems from the fact that as a historically small team, it didn’t seem to make a lot of sense to try and maintain multiple disparate platforms.    In the era when the team was divided between VB and C++ programmers, we often ran into a situation where developers from the VB side of the world were free, but C++ code needed a change, or vice versa, so when we could converge the team on C# and eliminate those pockets, it made resource management simpler and more effective; recognizing that has made me somewhat more reluctant to partition the team.

The classic ASP.Net Web form styled development we’d done in the past is clearly not the direction in which Microsoft is investing in the future.  Their focus is clearly on MVC and Razor  for web development, and in general, they are pivoting (in a more ponderous way than may have been good for them) to a development model that’s more similar to the way other web scale platforms address things.  Dino Esposito’s book says “You still have a mature and reliable platform that will be maintained for a few more years and supported for the foreseeable future.”  If we’re doing large scale reworking of the site – it doesn’t seem wise to invest in the platform that’s moving into maintenance mode.

So – if we’re moving away from the classic ADO.Net/Asp.Net Web form development work, where does one go?

In the Microsoft dev tools space, the work their doing around MVC for new development is clearly directionally interesting, particularly when coupled with the OWIN platform work that seems to position them to let you run the stack on top of things other than IIS.  This would seem to be a part of the infrastructure work that will let them run MVC web sites via Docker on Linux hosts.  The Enterprise Application Architecture for .Net 2nd Edition book does a good job of showing how you can use MVC in a way that’s compatible with a Domain Driven Design approach, with reasonable separation between the environmental/infrastructure world and the underlying domain logic, and it’s fairly clear that there are ways to bring Microservices into that umbrella.

The counter argument to this is that the momentum in for web / cloud scale sites is pretty clearly on the side of Java at the moment.

• Docker and it’s container kin have emerged from that space, as have large numbers of deployment and configuration management tools – and while the MS community is begining to grow similar capabilities in some places – they are playing catchup.
• There are certainly opportunities to bring in potentially valuable assets from the open source community, particularly some of the things coming from NetFlix OSS, they don’t have analogs in the Microsoft world.

My thinking at the moment is to continue to use the Microsoft ecosystem, but in a way where we minimize the exposure of “Microsoftisms” as much as possible.

• Domain Driven Design approach, with a CQRS approach to modelling the application layer interface.
• Micro-services
  • deployed as restful HTTP services.
  • No Datasets or other MS infrastructure components in any exposed service interfaces. Services return JSON or other XML based data collections.  This should let us consume those services from other technologies, and use other technologies to build replacements where we see fit in the future.
• Polyglot view of persistence.
  • The right Datastore for each module/micro-service.
  • If it’s our legacy SQL server platform, great.  Aggressive use of Hekaton and similar things could yield some advantages.
  • Open to things like Cassandra, Dynamo-db , Aurora.
• Agnostic as to the underlying web server platform
  • IIS is an option, but so is MVC in Docker containers under Windows Server w/ Docker support, or other platforms.
• MVC for the user interface, coupled to a well organized domain and application services model that separates the core business logic and processes from the presentation layer to allow us to make a change there later if needed without throwing out too much of the application.

My thinking is heavily influenced by:

• The availability of a solid, gelled team of developers with experience with the Microsoft tooling and development environment.
  • If I’m going to take them through an architectural generation  change, there’s something to be said for not forcing a language change on them as well.
  • They are generally productive in that environment today.
• That development team has significant domain knowledge and expertise that we need to use.
• There exists a body of code in place that offers opportunities to help us move this process along expeditiously with some refactoring, and generous use of adapters and anticorruption layers between systems.

Working conceptual glossary

This post is going to be revised to enhance definitions and add new ones, so I can keep track of the way in which I’m using the terms.  This may not represent the canonical definition in the outside world, particularly where there’s debate as to best practices – it’s just how I’m using them.

• Application Services
  Layer that sits on top of the domain model and implements the use cases for the application.  Typically, transaction scope and similar things are coordinated at this level.In an MVC based app, it can be useful to think of the controller using an instance of the application service to accomplish it’s work.

• Bounded Context – “A specific responsibility enforced by explicit boundaries”.
  A bounded concept represents a portion of a domain where the ubiquitous language is consistent, covering a defined conceptual part of the domain, with explicit boundaries between it and the other parts of the system.
• Domain Events
  Events exposed by the domain model/services to tell interested parties that something of interest has happened.  Allows those other parts of the system to use a publish/subscribe mechanism to indicate that they are interested.
• Domain Layer
  DDD – Made of up the Domain Model + Domain Services.
• Domain Services
  Conceptually, pieces of functionality described in terms of the domain language of the bounded context they live in that don’t make sense as a method on a single Entity in the domain model.  This is often a process that requires some coordination of multiple entities to accomplish a task that’s logically part of the domain.
• MicroService
  My working definition is a small service (Web Service, RPC accessible service, etc.) that exposes on or more application services from within a single bounded context.
  • Modelling should be driven around exposing behaviors from a service
  • It should be of a size that can be driven by at most, 2-3 developers
  • It may, and often should, have its own dedicated data store, organized in such a way as to optimize its performance of its duties.
    • Schema and technology can and should be specific to it’s role.
    • That underlying store and technology should be irrelevant to consumers of the service.
  •  It must expose a well defined, stable interface.  The interface may be expanded, but whenever possible, downward compatibility should be preserved.
  • The implementation of the Microservice can and should evolve freely, while preserving that stable interface to consumers.
  • Current default Microservice implementation should be JSON returning restful web service.

Current Reading list – 2/8/2015

• Building Microservices(Prerelease copy)
  Sam Newman
  Good conceptual overview of Microservice based approach, and it’s relation to DDD; some practical discussion of different implementation paths you might think about, etc.My biggest critique is that the theory would have been more comprehensible with more practical applications that should how this can/should be applied – Esposito’s book did more of that for the approaches they discuss.

  Also worthwhile for the discussion of the applications of DDD to this.

• Microsoft.Net: Architecting Applications for the Enterprise, Second Edition
  Dino Esposito, Andrea Saltarello
  More practical and approachable than Implementing Domain Driven Design; applies DDD in a Microsoft .Net friendly way.  He clarified some points that I didn’t get after a couple of chapters on bounded contexts in  Vernon’s book in a paragraph, and the book is generally approachable and practical.  Decent examples.
  A little concerned that there are some places where it’s a little quick to compromise on some aspects of DDD vs. the more prototypical  .Net approach, but generally includes a good discussion on the trade-offs being made.
• Domain Driven Design
  Eric Evans
  The canonical book on DDD from 2004.  Good overview of the initial thinking around this approach; some things have changed/evolved in the past 10 years to refine this approach.Worth reading for the conceptual model.
• Implementing Domain Driven Design,
  Vaughn Vernon
  This book was billed as an update and refinement to Evans Domain Driven Design. Verbose to the point of tedium; verbose enough to make you wish the content that was there wasn’t useful once you made your way through it.There’s some good information on DDD, and it adds discussion of architecture for actually implementing systems using this discipline, including CQRS, but the book really makes you work for the insight.
• NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence
  Pramod J. Sadalage, Martin Fowler
  Good general discussion of the notion of Polygot persistence, with special emphasis on NoSQL.  General notion here is to pick the appropriate data store for the problem at hand, without arguing about it’s global applicability.