Showpitch Advanced Part 1: Using Neat Architecture for Domain Services

After 3 weeks of high level review of Showpitch we’re going to dive in to more advanced topics. This week we’re going to cover the specifics of using Neat Architecture for Showpitch.

Neat Architecture

Showpitch uses the Neat Architecture to allow for very rapid development and a great amount of flexibility and power. You can find the Neat Architecture in practice on GitHub, so check it out when you have a chance! Now let’s get in to what Neat Architecture is.

Neat Components

Neat starts with several important components, all from NuGet:

  • ASP.Net Web Api
    • Microsoft.AspNet.Cors.5.2.3
    • Microsoft.AspNet.WebApi.5.2.3
    • Microsoft.AspNet.WebApi.Client.5.2.3
    • Microsoft.AspNet.WebApi.Core.5.2.3
    • Microsoft.AspNet.WebApi.Cors.5.2.3
    • Microsoft.AspNet.WebApi.Tracing.5.2.3
    • Microsoft.AspNet.WebApi.WebHost.5.2.3
  • Microsoft Practices Unity 3
    • CommonServiceLocator.1.3
    • Unity.3.5.1404.0
    • Unity.Interception.3.5.1404.0
    • Unity.WebAPI.5.1
  • OData
    • Microsoft.AspNet.WebApi.OData.5.5.1
    • Microsoft.Data.Edm.5.6.0
    • Microsoft.Data.OData.5.6.0
    • System.Spatial.5.6.0
  • NLog
    • NLog.4.0.1
    • NLog.MongoDB.0.7.0
    • mongocsharpdriver.1.8.3
  • JSON.Net
    • Newtonsoft.Json.6.0.4
    • Newtonsoft.Json.7.0.1
  • Octopack
    • OctoPack.3.0.42
  • MongoRepository
    • MongoRepository.1.6.8
    • mongocsharpdriver.1.10.0

Neat Solution Structure

The Solution Structure is comprised of a pretty traditional N-Tier stack. This stack is broken out in to a few more layers to facilitate further decoupling and reduce friction among components.

  • Neat.Model – All Domain Models
  • Neat.Data – Common Data Access Definition
  • Neat.Data.Mongo – Mongo Data Access Implementation
  • Neat.Infrastructure – Components for Application Functionality
  • Neat.Application – Core Business Logic
  • Neat.Service – Orchestration of Business Logic Components
  • Neat.Infrastructure.WebApi – Web Api Specific Functional Components
  • Neat.Web.Api – Web Api Host

A Closer Look at Unity and IoC in Neat

In Neat we use a class called Bootstrapper in each project to configure all Type Registrations for that project. We then expose an Attach method in each Bootstrapper, allowing components that rely on that project to run that project’s configuration against that component’s Unity container. Here’s an example:

public static class Bootstrapper
{
    public static void Register()
    {
        var container = new UnityContainer();

        Register(container);
    }

    public static void Attach(IUnityContainer container)
    {
        Register(container);
    }

    private static void Register(IUnityContainer container)
    {
        Neat.Data.Mongo.Bootstrapper.Attach(container);
        Neat.Infrastructure.Bootstrapper.Attach(container);

        container.RegisterType(typeof (IDomainApplication<>),
            typeof (DomainApplication<>),
            new ContainerControlledLifetimeManager());

        container.RegisterAllService<IApplication>();
    }
}

There’s a lot happening in this code:

  • The Attach Method – Components that depend on this one pass their container in here so that this component can register its classes on the same container
  • The Two Attach Calls – This component in turn calls Attach on the components it depends on
  • The typeof Registrations – This is how to register the generic implementation so that any type passed to the generic results in a resolvable type. Using this registration pattern throughout the stack these components can handle any domain object from the Web Api through to the Database
  • RegisterAllService – This is an Unity Extension in Neat that registers every class as the default registration for its other interfaces when it has the marker interface specified
  • ContainerControlledLifetimeManager – This lifetime manager ensures that the type registered is resolved as a Singleton

A Closer Look at the Web Api Controller in Neat

The Controllers in Neat use the generic Domain stack to expose the Domain Models. Here’s an example:

public class NeatController : BaseReadWriteDeleteController<NeatExample>
{
    public NeatController(IDomainService<NeatExample> domainService)
        : base(domainService)
    {}
}

As you can see, using the Unity registration from before and this Controller pattern, we’re able to rapidly expose Api Services for new Domain Models. But where are the methods? The answer lies in the BaseReadWriteDeleteController:

public class BaseReadWriteDeleteController<T> : BaseApiController where T : class, IEntity<string>, new()
{
    private readonly IDomainService<T> _domainService;

    public BaseReadWriteDeleteController(IDomainService<T> domainService)
    {
        _domainService = domainService;
    }

    // GET api/{T}
    [EnableQuery]
    public IQueryable<T> Get()
    {
        return _domainService.GetAll();
    }

    // GET api/{T}/{id}
    public T Get(string id)
    {
        return _domainService.GetById(id);
    }

    // POST api/{T}
    public void Post([FromBody]T entity)
    {
        _domainService.Add(entity);
    }

    // PUT api/{T}
    public void Put([FromBody]T entity)
    {
        _domainService.Update(entity);
    }

    // DELETE api/{T}/{id}
    public void Delete(string id)
    {
        _domainService.Delete(id);
    }

    // GET api/{T}/getempty
    [HttpGet]
    public T GetEmpty()
    {
        return new T();
    }
}

This pattern works very well with MongoRepository due to its generic implementation. Perhaps in a future post we’ll cover an Entity Framework Code First approach for this.

This architecture allows for very rapid application development. To add a new Domain Service to this stack the steps are simply:

  1. Add a new Domain Model
  2. Add a new Controller and inherit from the appropriate Base Controller with the right methods
  3. Profit!

In future posts we’ll cover how to add additional behavioral capabilities in to this architecture and extend it with other service features. Is there a specific part of this architecture that you have questions about? Is there another part of Neat you saw on GitHub that you want me to write about next? Please leave a comment below to let me know! And keep checking back for more info about Showpitch and Neat!

<< Back to Showpitch 103
On to Showpitch Advanced Part 2 >>

Advertisements

Showpitch 102: Let’s Review the Tech

So where we left off we covered what Showpitch is and what we’re setting out to accomplish. Now I want to review what technologies we’re using to accomplish our goals, and highlight a few of them in particular.

In the last post I had said I wanted to share what I’ve been working on for the past two years. Well Showpitch is not the entirety of that two year period. To start with, I only joined the Showpitch team about a year and a half ago. Even then, I didn’t step in to the architectural role for the product for another 3 months or so after that.

Before that was even the case though I had been working on other projects, exploring and experimenting with some of the technologies, patterns, and practices that we ultimately put in to place at Showpitch. For the first 3 months I was there, I was there as a Front End team member, helping to build some of the components that we were going to use for the UI at that time.

But then there was change in the team structure, and direction of the company, and as I had experience leading, architecting, and developing projects before I was asked to take over as the Senior Software Architect overseeing and implementing a from scratch reboot of the entire Showpitch platform, along with my good friend and colleague Eric Johnson (better known as EJ!) as a peer and partner in charge of the Front End team. (And lots of other stuff as well! In fact, if you’re all lucky, EJ may be convinced to add a guest post to this blog some day!)

By this point Showpitch had been developing this platform for quite a while. So with an entire reboot from scratch upon us, and expectations from stakeholders, partners, and other industry members ahead of us, one thing was very clear: We needed to move very fast. But with the vision that was in mind, we also needed to do things right, and keep where we were going in mind. We had to follow of the wisdom of two great minds: to be mindful of the future, but not at the expense of the moment.

This lead us to the list of modern approaches that appeared in the first post. Let’s dive in a bit more now and talk about the technologies, practices, and partners that we choose to implement and support each of those approaches.

Being Cloud First, Cloud Native

When we talk about being Cloud First, Cloud Native, what does that mean? For us it meant that we simply didn’t have the budget, people, or time to buy our own hosting hardware and software, nor to setup our own company computing environment. And that’s been to our benefit. Everything we do at Showpitch is on the Cloud; collaboration, development, management, and especially hosting.

We work with, leverage, and consume Cloud services from providers such as:

This is not an all inclusive list of the Cloud technologies and partners we leverage, but it should server as an example of just how cloud oriented Showpitch is.

Leveraging partner solutions where possible and economically viable

In addition to the Cloud First, Cloud Native approach, we also wanted to focus on delivering features and functionality with our platform, and not spend time building what others have already built, and probably built better. This stands in contrast to what I consider the NIH anti-pattern (Not Invented Here).

To that end we looked outside our team first for implementations of many of the features we have, including:

Again, this is not an exhaustive list. But the purpose of this approach was to start up quickly, and use the expertise and tools that each of these partners made available to support our development. We could have easily gotten caught up in building solutions for each of these components ourselves, but instead we were able to focus on developing our own features.

Leveraging technologies that allow for Rapid Application Development and Iteration

This was a very important approach to consider, perhaps the most important, as we had to demonstrate feature progress immediately. To the that end we needed to select application components that supported building this system very quickly. What we decided on were things like:

These are some of the technologies that have allowed us to quickly prototype, apply proof of concept, development, test, refine, iterate, and successfully deliver. I’d especially like to call out Unity and ReSharper here. Unity has been massively important to the design of our application and has allowed us to accomplish in handfuls of code what would have been entire projects otherwise. I will be posting specifically on a couple examples of this throughout this series. And ReSharper has increased productivity for our team across the board. Its Code Navigation and Refactoring capabilities alone have saved us dozens if not a couple hundred man hours across the team, and this includes the Front End Team who works largely in the realm of JavaScript (Yeah, ReSharper does that!).

Running on a very Lean and Agile Management approach

All of these technologies, tools, and partners would amount to naught though if we were constantly getting in our own way, or if we were constantly in a state of analysis and requirements gathering. As such we’ve had to find a fine line between staying organized and getting work done. So while our team oscillates between a Scrum-like approach and a KanBan-like approach, we still attribute a couple of key technologies to our success:

This combination of technologies has allowed us to work while distributed geographically, on a Cloud Oriented basis, without having to invest significantly in office management nor technology management.

Using only what we need, when we need it, and being ready to scale when the time comes

Through the use of everything we’ve already discussed we’ve been able to design for and adhere to this last approach. Almost of the Cloud partners and technologies we use are built to scale on demand, or near enough, that we don’t need to make huge up front commitments or investments. In fact we’ve switched providers and partners several times during the past year, sometimes in as little as day, with no disruption to our ongoing development!

All of this ties together in to a success story culminating in the live Showpitch site today, and continues to enable and empower our success moving forward.

Do you want me to focus on any of these technologies in future posts? If so, please leave a comment below! And stay tuned for more posts that will go in to greater detail about these technologies, practices, and approaches in particular!

<< Back to Showpitch 101
On to Showpitch 103 >>

Showpitch 101: Let’s Talk About Building Showpitch

Let me start by saying that I am aware it’s been a very long time since I posted to this blog. Honestly, the topic today, and the related topics to follow have a lot to do with that! But I’m back and I’m ready to share with you all what I’ve been working on for the past almost two years, so let’s begin!

There’s a lot to share with what’s gone into building Showpitch.com. This includes what Showpitch.com is, what its goals are, what technologies we’re using to make it successful, and the patterns and practices at work in its implementation. And then there’s how all of that ties together into a comprehensive eco system with many capabilities now and more planned for the future.

Today I want to start with talking about what Showpitch.com is and what a very high level overview of it looks like. I’ll go into more detail regarding its design, implementation, and specific capabilities in future posts.

In a nutshell Showpitch.com‘s stated purpose is to make talented people famous. This is a very simple concept, but very hard to make a reality. There’s a lot that goes into talent, discovery, fame, and the entertainment industry. Becoming famous isn’t easy, in fact it’s a lot of hard work! As the saying goes “If it were easy, everyone would do it.” So when you consider solving the problem of fame, you can easily see that this is a very hard problem to work on!

Showpitch.com‘s solution to this problem takes a very comprehensive approach.

We’ve identified the major forces involved in the talent discovery process:

  • Industry
  • Fans
  • Talent

Further, we’ve broken the process down in to many components:

  • Discovery
  • Engagement
  • Connecting
  • Collaborating
  • Funding
  • Development
  • Production

And with this in mind we’ve modeled the problem domain, and built tools and processes around each of these components. A short list of some of the tools and processes includes:

  • Fan Recruiting, Promotion, and Social Posting
  • Connecting between Industry members and Talent in a Social Network
  • Full Text Search across Talent, Industry, and Media
  • Deep Tag-based Search and Analysis across Talent, Industry, and Media
  • Showcalls and creating and publishing Opportunities for projects
  • Joint Ventures, Partnership Channels, and Industry Contacts
  • A Media Hub, allowing for Distribution and Consumption of Media

This starts to encompass the scope of features that are made possible through the Showpitch platform and specifically the Showpitch.com website.

With such a large feature set, and with the team size that you would expect for a startup, it quickly became evident that we were going to have to embrace several modern approaches to web application design to achieve success, including:

  • Being Cloud First, Cloud Native
  • Leveraging partner solutions where possible and economically viable
  • Leveraging technologies that allow for Rapid Application Development and Iteration
  • Running on a very Lean and Agile Management approach
  • Using only what we need, when we need it, and being ready to scale when the time comes

And so less than a year and a half into principle production development you can see the results at Showpitch.com. I encourage you to head over to the site, create an account, and check out some of its features!

After a lot of hard work there’s a lot we’ve gotten right. There’s also a lot of lessons we’ve had to learn. And I’m going to use the next several posts to this blog to share those with you. So stay tuned!

On to Showpitch 102 >>