Context is King: Finding Service Boundaries

Context is King: Finding Service Boundaries

Having explicit service boundaries is one of the tenets of SOA. Defining correct services boundaries is critical. I believe it’s one of the most important aspects of developing a system is finding service boundaries and it’s also really easy to get wrong.

This blog series is intended as a guide for finding service boundaries within a domain for the system you’re developing.

What’s a Service?

Before I get too far ahead, I better clarify what “service” means to me so we can be on the same page. If I can simplify it to a single sentence it would be:

A service is the authority of a set of business capabilities.

A longer explanation is a service owns all the business logic and data associated with a specific set of business capabilities in our system for our domain.

Here are some of the topics covered in this series.

Data Authority

Services should have full authority over the data they manage. The data that they manage should pertain to the capabilities it provides. No other service should be able to directly access or modify the data. If there is no capabilities provided by the service, it shouldn’t be a service, just a database.

Autonomous

Services should not rely on other code. They should be independent of each other. Prefer asynchronous messaging over RPC.

Services react to messages. The publisher of those messages doesn’t need to know if they were handled. The consumer of the messages does not need to know how they were created.

If RPC is required, create well defined interfaces for your service.

Language

It’s always amazing to me that language can have such a giant impact on understanding a domain which can help to define boundaries.

My classic example is using a warehouse/distribution system that has a Product entity. A Product isn’t a Product isn’t a Product.

Meaning a product in one service can represent an entirely different set of data capabilities in another.

Which then leads me to entities…

Entities

I’m not sure where the industry got fixated on entities. Domain Driven Design might be partly to blame for this. It also could be the likes of ORM’s and having mappings to tables that represent entities.

Whatever the reason, I think they do a giant disservice by taking away focus from what really matters which are business capabilities, not entities.

Blog Series

More on all of these topics will be covered in greater length in future posts. Stay tuned. If you have any questions or comments, please reach out to me in the comments section or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Explore DDD 2017 Review

I just returned from Denver, Colorado, where the first Explore DDD conference was held.  I originally heard about it earlier in the year on Twitter via the organizer Paul Rayner and decided to submit a couple abstracts for the CFP.

Fat Controller CQRS Diet

The talk that was accepted and which I delivered on Friday morning was my Fat Controller CQRS Diet talk.  The talk revolves around trying to decouple your application from top I/O layer or framework.  More info on the talk can be found in my series of blog posts as well as a episode of Software Engineering Daily podcast.

Domain Driven Design

I stumbled upon Domain Driven Design somewhere around 2010.  I actually found it because of watching a talk online from Greg Young making some indirect references to Domain Driven Design and CQRS.  The talk caught my interest and within no time I was captivated by DDD and CQRS.  I instantly went and purchased the book.  That was a very significant point in my software development career.

Explore DDD

The speaker lineup at this conference was simply incredible.  Eric Evans, Rebecca Wirfs-Brock and Ward Cunningham were the keynotes.  Crazy. I cannot really believe that I was chosen to speak at such a conference. Imposter Syndrome was maxed out to 11. It didn’t take too long to have some conversations at the conference to realize that I had different experiences and views that proved to be valuable.  This didn’t knock down the imposter syndrome completely, but definitely lowered it a just a tad.  On the other hand, the amount that I learned from discussions and talks were like no other conference.

Community/Family

This really summed it for me.  There was a real sense of community/family.  I can’t really put my finger on why that is but I have a few guesses.

Conference Space/Location

Incredible.  38th Floor of the Grand Hyatt, looking over downtown Denver.  The floor itself was broken down into 3 track rooms, general gathering room where food was served, as well as a unique blue track room.  The blue track was reserved for spontaneous modeling, discussions, problem solving, whatever.  I actually had several interesting discuss here and it was kind of a good place for the “hallway” track in some respects.

Paul Rayner

The conference kicked off on Wednesday evening with the keynote by Eric Evans.  Paul spoke to intro the conference as well as each day with some house keeping notes.  I felt the way Paul gave such a calm welcoming, really set a tone for the entire conference.

Thank You!

Hands down an awesome conference.   Thank you to Paul for organizing an incredible event and selecting my talk.  All the attendees and speakers (from all over the world!) for making it feel like a family. I highly recommend attending this next year.  I hope to see you there!

Domain Driven Design: “What” not “How”

Common LanguageMany years have past since Eric Evans release the blue book: Domain Driven Design.  A lot has changed over the years but I find the core ideas still hold very true.

In some ways, I think some of the concepts outlined are even more prevalent now than they have ever been.

Ubiquitous Language

The Ubiquitous Language is a shared language developed by the team.  The team is everyone working on the project: developers, domain experts, QA, BA.

Everyone on the team.

The ubiquitous language isn’t developed by the domain expert(s) alone.  If you have more than one domain expert, they may struggle with language between each other to define concepts.

Everyone apart of the team is building, growing and refining the language.

Language is critical to not only verbal communication but how it’s represented in the software we are writing.  It represents the concepts and terms specific to the core business domain we are trying to model.

All the expressions, nouns and verbs are what the team is formally defining with an ubiquitous language.

Bounded Context

Boundaries

One of my favorite concepts is of the bounded context.  Bounded context should be autonomous.

Meaning, a bounded context should be independent and self governing.

It defines a set of business capabilities within the domain and represents a conceptual boundary.

One way of determining where the boundaries lie is with the ubiquitous language.

If a term or phrase has a different meaning in another context, you may have discovered a boundary and therefor another bounded context.

“What”, not “How”

With the rise/hype of microservices, the concept of a bounded context continues to hold true.

How do functional languages impact domain driven design?  As I’m leaning F#, I’m not overly concerned about the “how”.

The important part modeling a domain for me is the verbs, not the state.  I do think that will translate well to a functional language.

Focusing on the what not the how is what makes Domain Driven Design still very important and applicable so many years later.