To Microservice or not to Microservice – helpful links and resources

Microservices is an approach to application development in which a large application is built as a suite of modular services. Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other modules.

Microservices introduction:

Introduction to Microservices Whitepaper

Microservices pattern

The initial white paper on microservices by Martin Fowler and James Lewis (it is a bit dense, but it highlights the intent of this architecture and it is one of the first whitepapers published on the subject):

Martin Fowler’s whitepaper

Using API gateway to get coarser calls and group microservices:

API Gateway pattern

Foreign Key relationship conundrum:

Foreign Keys and Microservices

Distributed transactions and microservices, how to keep referential integrity:

Distributed Transactions Strategy in Microservices

Netflix whitepaper:

Netflix Architectural Best Practices

IASA Free Resources/Whitepapers:

Why to choose Microservices

Successfully implementing a MSA

And finally, if you have a pluralsight trial subscription and you prefer to watch a video instead of reading a bunch of articles, this course is a good introduction to the pattern, the MSDN Professional subscriptions should include a few courses trial at Pluralsight for free:

Pluralsight Training

Happy design and coding!

I need to get rid of that switch statement. What is the Strategy Pattern?

I’m a big advocate of software maintainability and there is nothing better for that than applying well known patterns to improve the existing code. Each time I see long if..then..else constructs, or switch statements to drive logic, I think of how much better the code would be if we allow encapsulation and use one of my favorite behavioral pattern… => the Strategy Pattern.

StrategyPatternA Strategy is a plan of action designed to achieve a specific goal

This is what this pattern will do for you: “Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.” (Gang of Four);

Specifies a set of classes, each representing a potential behaviour. Switching between those classes changes the application behavior. (the Strategy). This behavior can be selected at runtime (using polymorphism) or design time. It captures the abstraction in an interface, bury implementation details in derived classes.

When we have a set of similar algorithms and its need to switch between them in different parts of the application. With Strategy Pattern is possible to avoid ifs and ease maintenance;

Now, how can we digest that in code, now that you got the gist of the problem and want a better solution than your case statements.

This example I’ll be showing is a pure academic exercise:

The problem to solve is given a string as an input, create a parsing algorithm(s) that given a text stream identifies if the text complies with the following patterns. Angle brackets should have an opening and closing bracket and curly brackets should also have an opening and closing bracket, no matter how many characters are in the middle. These algorithms must be tested for performance.

<<>>{}  True
<<{>>}  False
<<<>    False
<<erertjgrh>>{sgsdgf} True

Continue reading I need to get rid of that switch statement. What is the Strategy Pattern?

Technical Debt – What it is and what to do about it

The following paragraphs in italic are taken from an article in IASA (International Association of Software Architects) written by Gene Hughson

In spite of all that’s been written on the subject of technical debt, it’s still a common occurrence to see it defined as simply “bad code”. Likewise, it’s still common to see the solution offered being “stop writing bad code”.  It’s not that simple.

What is Technical Debt?

A design or construction approach that’s expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time) .

Technical debt may not only incur costs due to rework of the original item, but also by making more difficult changes that are dependent on the original item.

Deferring bug fixes is a form of technical debt as is deferring automation of recurring support tasks.

Dependencies can be a source of technical debt, both in regard to debt they carry and in terms of their fitness to your purpose.

The platform that hosts your application is yet another potential source of technical debt if not maintained.

As noted above, the “interest” on technical debt can manifest as the need for rework and/or more effort in implementing changes over time. This increase in effort can come through the proliferation of code to compensate for the effects of unresolved debt or even just through increased time to comprehend the existing code base prior to attempting a change.

In short, technical debt is any technical deficit that involves a risk of greater cost to expand the application and/or end user dissatisfaction.

What to do about it?

Becoming aware of existing debt is a critical first step, but is insufficient in itself. Taking steps to actively manage the system’s debt portfolio is essential. The first step should be to stop unconsciously taking on new debt. Latent debt tends to fit into the immediate, unexpected payback model mentioned above. Likewise, steps taken to improve the quality up front (unit testing, code review, static analysis, process changes, etc.) should reduce the effort needed for detection and remediation. Architectural and design practices should also be examined. Too little design can be as counter-productive as too much.

Just as the taking on of new debt should be done in a rational manner, so should be the retirement of old debt.

Think of technical debt as credit card debt and you’ll realize why it is important to account for it, be aware of it and pay it off before funding any new features.

Domain Modeling, why it is replacing Data Modeling and bottom up designs

Complexity is the driving force for the adoption of the Domain Model pattern. Complexity should be measured in terms of the current requirements and what processes are modeled or automated by the application.

A domain model is a collection of plain old classes, each of which faithfully represents a significant entity in the business domain. These classes are data containers and can expose public properties, but they also are expected to expose methods. The term POCO (Plain Old CLR Object) is often used to refer to classes in a domain model. At some point, the classes in the domain model needs to be persisted. Persistence is not a responsibility of the domain model, and it will happen outside of the domain model through repimageositories connected to the infrastructure layer.

The conversion between the model and relational store is typically performed by ad hoc tools— specifically, Object/ Relational Mapper (O/ RM) tools, such as Microsoft’s Entity Framework or NHibernate. The unavoidable mismatch between the domain model and the relational model is the critical point of implementing a Domain Model pattern.

For decades (1980 to 1990s), relational data modeling was the most effective way to model the business layer of software applications. In the .NET space, the turning point came in the early 2000s, when more and more companies that still had their core business logic carved in the rough stone of mainframes took advantage of the Microsoft .NET Framework and Internet breakthroughs to renovate and modernize their systems. In only a few years, this poured an incredible amount of complexity on the shoulders of developers. RAD (Rapid Application Development) and relational modeling then— we’d say almost naturally— appeared worn out and their limits were exposed.


All the text above was taken from “Esposito, Dino; Saltarello, Andrea (2014-08-28). Microsoft .NET – Architecting Applications for the Enterprise (2nd Edition) (Developer Reference)” with permission from the authors.

Complexity is tackled best using classes that model the business with ubiquitous language. Language that is understood by the technical modelers (software architects/developers) and by the business counterparts or system matter experts. Domain Services encapsulate services that can be consumed by other applications or different GUIs. The focus now is in modeling the domain and modeling the behavior, rather than modeling the data (RDBM) model without events or behavior. The data model, as a starting point in the design, falls short without modeling the sequence of events (behavior) and the flow of information.

Selling my book collection at Amazon…

I recently moved to a smaller place and can’t keep all my technical book collection.

I’m selling the books that I already read, no longer need or have duplicates. Some of them are for old .NET frameworks, but if you are maintaining legacy applications with these framework versions, the books from Microsoft Press can be helpful.

There are also books about SOA and SOAP, SQL Server specific books etc. The books are selling pretty fast.

You can access my seller’s collection at Amazon here.

All the prices are set for shipping within the USA only.

Happy coding!

The Eight Fallacies of Distributed Computing

Almost everyone, when they first start building a distributed application, make the following eight assumptions. All are proven to be false in the long run and cause trouble and painful learning experiences:

  1. The network is reliable
  2. Latency is zero
  3. Bandwidth is infinite
  4. The network is secure
  5. Topology doesn’t change
  6. There is one administrator
  7. Transport cost is zero
  8. The network is homogeneous

Keep the points above in mind when you design a distributed application. They are fallacies that increase the maintenance costs of your distributed application.

Book Collection for a Junior Architect

Design pattern books:

1.       C# 3.0 Design Patterns

2.       Design Patterns: Elements of Reusable Object-Oriented Software:

3.       Patterns of Enterprise Application Architecture

This book is a must

4.       Microsoft .NET: Architecting Applications for the Enterprise (Pro-Developer)

5.       Microsoft Application Architecture Guide (Patterns & Practices) (This one can be downloaded for free as PDF from msdn)

6.       Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (This book is really good for specializing in middle tier aka services, queues etc)

7.       Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition)




Domain Model Pattern (These books are dealing only with the DM pattern)

1. Applying Domain-Driven Design and Patterns: With Examples in C# and .NET

It has examples in C# 2.0 but the concept (DM) is still valid nowadays.

2.       Domain-Driven Design: Tackling Complexity in the Heart of Software

This is a classic although the book is a bit dense, see the examples. The book is narrated as a story when the author was developing an application for embedded electronic circuits.


Inversion of Control Pattern/IoC:

3.       Dependency Injection

Internet Architectures (Load balancing, redundancy, ways to scale out)

4. Scalable Internet Architectures

5. The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise

These two are “must have”references, specifically the UML one:

6.       UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)

7.       Refactoring: Improving the Design of Existing Code

And to translate from the Object Oriented World, Class Diagrams and UML notation to the Entity Relational World with Entity Relationship Diagrams:

8. Agile Database Techniques: Effective Strategies for the Agile Software Developer (Wiley Application Development)

9.       Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series (Fowler))

Thanks to Srinivasa Tammana for asking me to put this list together. I own other titles but they are more detailed to a particular database technology or programming language and the books here are long time favorites.


Estimation, that part of a project every developer dreads…

I was reading the IASA forum and found this article that summarizes a few truths about project estimation. I’ve been more than once haunted by time estimates I’ve given and I tend to be very conservative, to the point of having my estimates always frown upon.

Here are some tenants:

1.    It is relatively easy to estimate what you know.
2.    It is difficult to estimate what you know you don’t know.
3.    It is very difficult to estimate what you don’t know you don’t know.

And here is a thought that makes more sense to me. Having tried waterfall, mandate, wishful thinking from management etc in my many years as developer, this to me makes more sense:

Agile is not an estimation methodology in and of itself, and it does not generally develop estimate in units of time. Instead, estimated units of work are used. The units of work do not directly map to time until you have calculated your team velocity. Once the velocity is determined, it can give you a pretty good idea as to how long it will take to complete your project – that is for the body of work in the project that you know of and understand.

And here is the link to the complete article, it is worth reading every line with attention :)…

Are we there yet?

The concept of test beds or velcros for software modules…

Last week I attended a conference by Mario Cardinal at MSN Canada. The conference was part of the Toronto Architecture User Group.

The presentation had quite a few valid points along with the concept of “velcro” or test bed for modules. Test beds are a very familiar concept in electronics. In order to test hard drives or dvd drives, the manufacturer create test beds as opposed to test the parts in a computer. The same line of reasoning applies to software.

Here’s a Tech Ed 2009 presentation by Mario Cardinal.
Download Video

I look forward to see the code from this presentation at CodePlex and see what Mario Cardinal will blog after the Alt.NET conference in Vancouver, whether the same approach can be achieved with mocking frameworks.

Today (June 15th) I found the code for the Velcro project at Hope this helps you evaluating this concept:

Happy coding!