Just another WordPress site

Menu

Uncategorized

Last week I gave an initial presentation for our API Design Guild at work and I presented a variety of API Design scenarios using not only REST API examples but older ones such as C libraries, microcontroller libraries, and binary protocols. I think I just about lost everyone when I put up a picture of a microwave panel! My point was that the API is truly the Application Programming Interface. This is how we communicate with something and get it to do what we want. I think a lot of the API articles we have seen the past five years are all about the new web world where Javascript is king and JSON flows freely. But the API design is really about how the application acts when spoken to and has little to do with its surrounding, language, or framework used to build it. I watched this thirty minute presentation on API Design today by Mike Amundsen and I think it might clear up some of my inability to explain my thoughts on API Design that I presented a couple of weeks ago. Basically it is the concept of separating design from the implementation details.

What I find fun about API Design is the fact that you are creating a new entity and deciding how it interacts with the world. The language, framework, internal connectivity, and persistence layers are totally irrelevant at this point and it is best if you can somehow completely ignore them.

In the business world, Event Sourcing is essentially keeping track of all important events that happen within an organization in the order of occurrence and never modifying these events. The good part is you can probably keep your current database structure while still putting these event streams into place. The idea is that an event (typically defined as a small class of primitive types) is published by one system and any other system can subscribe to these events and act on them if needed. For example, let’s say we are developing a new consumer web site and a new customer sets up an account through a web page. As part of the process in persisting the customer data, an event is also published telling others that there is a new customer in the system. Some other business processes that might want to know about this new customer are a communications system that perhaps sends out a welcome email and another process that starts the aggregation of data to help fit our web site to the customer’s interests and profile they just entered during signup.

Three good reasons event streams are good for business:
1. Audit Trail
2. Easier Setup for Testing
3. Human readable sequence of business events

In my mind, it’s easiest and best understood to create software systems that model the world we live in. Events are occuring all around us constantly and all at the same time. We can’t go back and change the past; instead we react to these events and create new events to change things the way we want.

By using an Event Source on customer events, it is simple to look up events by customer number in the order they occurred. Having these events makes functional testing much easier. By having an input of one event, the assertion on the outcome of that event applied to some business process code becomes much easier. By having these events available and assuming you’ve defined your Ubiquitous Naming among all of the business, then walking through scenarios and making new Gerkhin Format test cases should be a lot easier.

Here’s a few links to people in industry that have either created/coined some of these names and patterns or are well-versed in their design and implementation details.

I’ve been working on a book the past year or two and it’s been a slow-going process. At the moment the name is ‘How to Build an Event-Driven Enterprise System’ and I’ve got it up on leanpub. If you’re interested, please sign up for updates on the site and I’ll start pushing out sample copies as they are available.How to Build an Event Driven Enterprise System

I’m really excited about the release of Akka.NET 1.0 as I’ve been working in C# as my day job for the past 7+ years and this will give me a chance to integrate it into some production code soon!

I remember finding this conversation with Carl Hewitt, the inventor of the Actor Model, online at MSDN Channel 9 after the podcast and suggest this as something people might want to take a look at to find out more on the Actor Model.

The Actor Model was created back in 1973 and it is not a new concept. It is, however, fairly new to the world of Java and C# where a lot of us have been the past decade. Basically an actor is defined as a ‘unit of computation’. Data is not shared between actors and all interactions is done through message-passing. If you’ve ever done any threading and concurrency programming I think you’ll appreciate the model.

An Actor can do several basic things:
1. Receive a message
2. Send a message to another Actor
3. Create new Actors
4. Change state

Petabridge.com has a really nice series of tutorials for Akka.NET named Akka Bootcamp. They will send you an email lesson a day for a few weeks or you can go to the web site and pick and choose which ones to work on. I prefer the email task per day as it keeps me going and on track. I’m a little over halfway through them currently and think it’s a great way to get started.

Chapter 4 is on architecture and is a long one. Vernon compares layered architectures with hexagonal ones, pointing out the advantages and disadvantages of each. He also walks through CQRS (Command Query Responsibility Segregation) and many options for implementing it as well as the pros and cons. He steps into Fabric/Grid Computing as well as a useful feature to use in Event Sourcing.

Here is a good place to note that in the book that are many, many references to chapters farther in the book. This is fair since the book does build on other books and the reader should have at least a knowledge of the concepts being discussed throughout. My suggestion is if you know a little something about these more advanced subjects, continue on as it will all come together in the end. If you really don’t feel comfortable continuing on without further knowledge, go ahead and peek ahead or hit up wikipedia real quick.

Implementing Domain Driven Design is a new book (2013) by Vernon Vaughn that expands on the works of Eric Evans and Jimmy Nilsson, two influential authors of the past decade. Vaughn starts by giving an overview of the book and what to expect. Like a of people, I suppose, I assumed because I created a model and thought hard about the object relationship that I was doing DDD. As Vaughn points out from the beginning, this is referred to as DDD Lite.

So far I’ve made it through Chapter III and we’ve covered Domains, SubDomains, Generic Domains, Bounded Contexts, Context Maps, and examples of when to use certain techniques. I really identify with the ideas in this either because I’ve had the same ideas myself and am glad to see other people also using these ideas or because they are concepts I generally agree on: keep it as simple as possible, separate concerns, and communicate clearly.

Isn’t the web already functional, you say? Yes, it is. And that’s a big part of the topics you’ll see on this site. I’ve always believed in basic components and simplicity when designing products over a wide range of domains. Software, electronics, and furniture design are all examples of subject areas I work with and I find a real beauty in applying simplicity to all of them.

The goal of this site is to provide articles, tips, and links on functional programming techniques to help others learn these techniques and apply them to not only web development, but any type of software development including enterprise architectures, mobile applications, and embedded system development.