Check it out here:
API Design Methodology
The seven point procedure that Mike Amundsen talks about in his presentation and starts off with ‘What is a design methodology?’
1. List the Semantic Descriptors
2. Draw a State Diagram
3. Reconcile Names
4. Choose a Media Type
5. Write a Profile
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.
Good luck on your next API Design!
Thanks for listening,
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.
Greg Young’s EventStore Github
Greg Young on Why Use Event Sourcing
Martin Fowler on Event Sourcing
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
Thanks for listening,
I’ve been keeping my eye on Scala, Akka, and the Actor Model since I listened to a podcast on Software Engineering Radio with Jonas Boner a few years ago:Episode 178: Akka With Jonas Boner. I’ve read Jamie Allen’s Effective Akka book as well as taken a couple of courses on Coursera involving functional programming and reactive programming: Functional Programming Principles in Scala and Principles of Reactive Programming.
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.
Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know, but were afraid to ask)
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.
I’ll write more on this later as I get farther down the road.
I’m planning on contributing some code samples on github if all goes well.
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.
Next up: Entities
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.
Get the book here on Amazon
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.