Architecture

Modeling Aggregates in DDD

Thomas Jaeger Architecture, Domain Driven Design

Here are a few notes I wanted to point out when you are trying to model aggregates in domain driven design (DDD). Many times I can’t find the right words or I simply forget what the technical definitions are when you model your domain model or any parts of a domain model such as aggregates. I always go back to the fantastic book “Implementing Domain Driven Design” by Vaughn Vernon. He is a master in showing and explaining it in such a way that I can not do a better job. As I’m currently doing some modeling work over the weekend, here is a summary from how Vaughn is explaining it:

“When trying to discover the Aggregates in a Bounded Context, we must understand the model’s true invariants. Only with that knowledge can we determine which objects should be clustered into a given Aggregate.“

He talks of how you should design your aggregates. What does an aggregate consist of. So, he goes on with another perfect explanation:

“An invariant is a business rule that must always be consistent.”

Followed by another super explanation:

“Aggregate is synonymous with transactional consistency boundary.”

In the past, I made the mistake of clustering aggregates via composition: “This object A contains object B” which is wrong. Once you understand the bounded context and the aggregate’s true invariants (the business rules), you got it. You hit the jackpot. The light will come on.

Anyways, I wanted to publish this for some time now but never bothered since I always go through Vaughn’s book. But, I thought others might find this useful information especially if you are doing domain driven design and microservices.

Updated C# Reference Implementation

Thomas Jaeger .NET, Architecture, C#, Design, Design Patterns , , ,

I have updated my C# reference implementation and included FluentValidation on some of the DTO objects. I also updated the ErrorMap to include validations on the server side as well as on the WPF client side. This version also includes a sample SQL Server Persistence Provider. As always, you can get the latest code on my GitHub repo.

Presenting “Object Persistence in C#” in Sacramento, CA, March 25th, 2015

Thomas Jaeger .NET, Architecture, AWS, C#, Cloud Computing, db4o, Design, Design Patterns, Presentation , , , , , ,

Wednesday, March 25th, 20015, I will be presenting “Object Persistence in C#” at the Sacramento .NET User Group (SAC.NET) at the Microsoft Office at 1415 L Street, Suite 200, Sacramento, CA 95814 starting at 6:00 pm. Maria Martinez, Co-Organizer, Sacramento .NET User Group, was kind enough in helping to get this organized. Thank you Maria. I will see you there.

Presenting “Object Persistence in C#” at Bay.NET User Group on April 9th, 2015

Thomas Jaeger .NET, Architecture, AWS, C#, Cloud Computing, db4o, Persistence, Presentation , , , , , , ,

I will be presenting “Object Persistence in C#” at the Bay.NET user group at the Berkeley City College located at Room 451A, 2050 Center Street, Berkeley, CA from 6:15 pm – 9:00 pm.

Deborah Kurata, Co-Organizer, East Bay Chapter Leader, was kind enough in helping to get this organized. Thank you Deborah.

I will see you there.

Object Persistence, Part 5 – Video – Redis Provider

Thomas Jaeger .NET, Architecture, AWS, C#, Cloud Computing, db4o, Design Patterns, Persistence , , , , , ,

In part 4 of this series, I went through the entire Visual Studio solution and also showed the db4o object database provider.

In part 5, I’ll show you how to store your Plan Old C# Objects (POCO) into Redis using the Redis Cloud at redislabs.com service. We will build the Redis Provider and take it out for a spin storing our new domain objects.

You can download the source code at GitHub.

Object Persistence, Part 4 – Video

Thomas Jaeger .NET, Architecture, AWS, C#, Cloud Computing, db4o, Design Patterns, Persistence , , , , ,

In part 3 of my Object Persistence series, I introduced the complete Visual Studio 2012 source code.

This is part 4 of my Object Persistence series. I created a detailed video that goes thru all the parts in the solution. Enjoy! Make sure you continue with part 5 where we build a Redis persistence provider.

Watch the video walkthrough on my YouTube channel:

Object Persistence, Part 3 – Source Code

Thomas Jaeger .NET, Architecture, AWS, C#, Cloud Computing, db4o, Design, Design Patterns, Persistence , , ,

In part 2 of my Object Persistence series, I’ve touched on the issues that still exist today.

In part 3, I’ve published a complete sample Visual Studio 2012 solution on GitHub that demonstrates object persistence using a db4o persistence provider. Over time, I will add additional sample persistence providers for Redis, SQL Server, and possibly a NoSQL provider such as SimpleDB (one of Amazon’s great NoSQL databases).

This sample solution includes complete server side and client side layers. The Server side runs as a REST based Web API 2 service. The server portion also includes a simple domain model and, of course, the persistence provider and how it is implemented. I will update the solution over time, expand the domain model, UI, etc. as required.

The client side is a WPF application that consumes the REST service. The payload to and from the REST service is via JSON objects.

ObjectPersistencePart3_WPF

I hope you like it. You can use this sample solution as a template to start simple or very complex software solutions. This solution can easily be taken and split across different nodes in a cluster of Amazon AWS EC2 instances, for example. However, for a cloud based solution, your persistence would have to support certain features. I will go into details when I add the Redis persistence provider.

Instead of writing a very long blog post, I will post a screen cast video and go through the solution. I think this will make more sense and you have a chance to go through the source code with me. So, go ahead and get the latest version from GitHub and start playing with it.

Object Persistence, Part 2

Thomas Jaeger .NET, Architecture, C#, db4o, Design Patterns , , ,

It has been several years (six years to be precise) since I published my article “What is Object Persistence”. I have received great feedback since then from the blog post and from presentations I gave about object persistence. However, the challenge of using an appropriate object persistence mechanism still exists today. Fortunately, there are even more ways to store your objects nowadays when compared to 2008. With the great opportunities that cloud computing offers, object persistence gets even more exciting.

So, I decided to publish a follow-up blog post about object persistence. In addition, I will also provide working C# code so that you can try it out yourself. Since object persistence is such an important piece of a software architecture and the depth of technical information about it can be overwhelming, I may have to spread out my thoughts and example source code over additional blog posts.

Most of the example source code I will be providing is coming straight from production systems I have built over the years with .Net and C#. Specifically, I will be providing persistence providers that you can use in your own systems or at least provide you with a huge head start. Some of the source code is changed to accommodate the example better but the provider pattern and the overall design is identical. The source code will be in C# and I will be using a .Net feature that has been available since .NET 2.0 – The Provider Pattern.

So, having said all this, I can pickup where I have left off with my first blog post. Say, you are familiar with the challenges of finding the right object persistence for your project. Let’s also assume you know “where” you want to store your objects in. If you are not familiar of what object persistence is, please take a look at my previous blog post “What is Object Persistence”.

Let’s start with a straight forward object persistence that will help you see the bigger picture and not get lost in the actual details of “how” to store the objects. At least for now. Let’s start with storing our objects in an object database named db4o. The reason why I want to start out with db4o is because it actually is the easiest way in .Net to persist your objects. I would argue that object databases can be used in at least 90% of .Net projects developed today. db4o has another advantage in that it can also run entirely in memory alone which is great for unit testing your persistence. In addition, db4o has such an extremely low learning curve that you will be up and running in no-time. Of course, the beauty of using a provider model is that you can do entirely different persistence implementations of the same domain model. So, you can use a different object database such as VelocityDB, for example.

Later on, I will show you how to store the same C# objects in different ways including the in memory version of db4o, a NoSQL solution such as Redis, which is a key-value store, and to round it out, a typical SQL storage such as SQL Server.

From an architecture point of view, it is very, very, important that our domain model has absolutely no clue about persistence. Our domain model will have no references to any persistence assemblies. Our domain model will be a lone assembly with no references to any service, interfaces, UI, and especially any persistence technologies. This is important because we want our domain model to be maintainable over time. You want your domain model to be independent from any other building blocks of your architecture because it will reflect your business domain and processes. This will make your entire system much easier to maintain and therefore much easier to react to requirements changes.

The Provider Model

The great thing about using the provider model is that the entire implementation is done inside a provider. Your entire source code on “how” to persist your objects is inside the specific provider. If you are not familiar with the provider model, please take a look at these resources to get familiar with it.

Microsoft ASP.NET 2.0 Providers: Introduction

Develop Provider-based Features of Your Application

Besides the introduction of generics in .NET 2, the provider model was in my opinion one of the most powerful features introduced. The .NET framework has been using the provider model internally ever since, all the way to the latest version of .NET 4.5. Here are some examples, where Microsoft is using the provider model:

Membership
Role management
Site map
Profile
Session state
Web events
Web Parts personalization
Protected configuration

and these are just a few of the current providers that ship with the framework. You can even build providers based on certain features of your system, for example. See the link above.

One of the great features of the provider model is that the framework will automatically load your persistence provider based on configuration information. This means that you do not even need any assembly references to your provider, the .NET framework will take care of the discovery, loading, and instanciation for you. This offers a truly decoupled implementation, a true plug-play mechanism out of the box. How cool is that?

Please keep in mind that this has nothing to do with the Repository pattern. I have used the provider model pattern for persistence for many years now and the Repository pattern does not come close to what the provider pattern can do for you. The Repository pattern violates the domain model encapsulation because the domain model is now aware of some sort of persistence idea even if the Repository is exposed via IRepository, for example. That is a big no no in my book because your goal should be to create something that is easy to maintain over a very long time.

If you are building a professional software solution, you should go with the provider pattern for abstracting persistence.

This took longer than I thought but I believe that I needed to set the stage first before we can continue. In the next blog post, we’ll get our hands dirty and start writing code and you will see how it can be done.

Continue with part 3, Object Persistence

The HTML5 Hype vs. Native Application Performance (Again)

Thomas Jaeger .NET, Apple, Architecture, Design, Steve Jobs

The latest buzz is all about HTML 5 and how it will improve our lives as architects, developers, companies, consumers of HTML5 applications and whoever else is getting sucked into this.

I’ve been doing professional software development for over 21 years now.  Over those years, I’ve used many different technologies. HTML 5 is just another “technology”. First of all, let me clarify in simple terms: HTML 5 is NOT a new technology. HTML 5 is based on existing technology called JavaScript, CSS 3 and HTML. None of these are new. What is new is the way it is being presented and marketed.

You see, I take the stand of delivering the best user experience to the consumer. What I mean by best user experience is this:
1.    Your users should “love” to use your software
2.    Your users should feel connected to your software
3.    Your software should accomplish what it said it would do for them, all the time
4.    Your software should do all things extremely fast
5.    Your software should look and feel top notch and professional, nothing less

As you can see from the list above, there are emotional connections between great software and their users. When you have human feelings involved with something as technical as software, you have subjective views on what great software means depending on who you ask. In addition, since most software is created for consumers, you will have to deal with emotional connections of your software and the consumers. You cannot afford to ignore your consumers’ feelings and perceptions of your software.

When you look at the industrial industry, physical objects such as a piece of furniture, a toaster oven, a recording device, etc. have aesthetics to them that triggers an emotional connection between the consumer and the physical object. Some consumers like a particular furniture and some others don’t. But, what is common between the different types of consumers is that they have a emotional connection or not. They like or don’t like a certain type of couch, for example. The design efforts that went into creating a successful piece of furniture maybe based on many factors.  Great designs are aesthetically pleasing and functional at the same time.

For example, look at the success of the iPhone or iPad. Here are devices that not necessarily have brand new technology inside them; but, they are packaged and presented in a way that is aesthetically pleasing to a lot of consumers. Moreover, they perform really fast and do it well all the time (disclaimer: nothing is perfect).  They both feel snappy. They both are easy to use and the content layouts (the user interface) are well thought out. They both are a total hit for Apple.

What would the iPhone or iPad be like if it had an Android or a Windows user interface? Would it still be a hit? Would consumers still love them? Would they buy them? Even worse, what if, both, the iPhone and iPad only had a Web Browser interface? How would consumers have reacted with their purchasing power?

What the iPhone and iPad have both in common is “fast” user feedback. This fast user feedback is, for the most part, is accomplished with native applications that take advantage of the device’s hardware. By native applications, I mean applications that are compiled into machine code for ultimate performance. In case of iPhone and iPad applications, this means that these applications have been developed with Objective-C on the Cocoa framework for iOS.

I’m certain that Steve Jobs had his hands in the user interface design decisions. I’m also certain that he would NEVER accept slow performing applications. If this is the case, I agree with Steve Jobs 100%. I agree because I believe that performance of software is even more important today than it was 20 years ago.

Software is created for people, most of the time. Consumers are spoiled with instance gratification. Consumers expect software to be fast. Consumers expect to get results, fast! People have less time and are doing more at the same time. Slow performing software is bad quality software, period. As a software creator, why would I want to settle for bad quality software? If you create the best software and want to make a living at the same time, you must create software that allows consumers to feel that emotional connection.

With that being said, when I hear things like HTML 5, I see Deja vu. I have seen this with Java, Visual Basic, .Net, ActiveX, Silverlight, etc.
These “new” technologies were created for many reasons and not one of them was created with the consumers in mind. These technologies such as HTML 5 were created with the intention to make things easier for the developers and the companies these developers work for.

The more abstract these technologies are, the more layers there are between the device and the output or user interfaces. The more layers there are, the slower the performance of the software. This principle has not changed in decades no matter how fast the hardware becomes.

At the end, the consumer can clearly see a difference in natively compiled software that was created for that native operating system and software that has these layers of translations that made it so simple for the developer.

This convenience for the developers costs dearly for the company who is selling the software in the long run. If a company truly cares for its target audience, then they better make sure that the emotional connection between the software and the consumer exists. The best way to do this is not to go the easy and lazy route but go the extra mile and develop the software in a computer programming language that has a native compiler. I can think of C++ or Delphi, for example.

Update 2012-04-09: Betting $1 Billion On Instagram, Facebook Backs Away From HTML5
http://www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2012/04/09/businessinsiderbetting-1-billion-on.DTL