When you boil down any typical ecommerce business shipping products to customers, the conceptual system architecture for this tends to be fairly standard the world over. Yet if you’ve only ever either been a Customer or you may never have been involved across all the different areas of the end to end process. Working in the world of Software Engineering, System Architecture and Enterprise Architecture, you often get a much better understanding of how everything connects together. 

It can be a challenge to understand the bigger picture if you’ve only ever had exposure to a handful of pieces of the complex jigsaw puzzle. So the purpose of this ecommerce conceptual data model is to help provide some context around the common interactions between an ecommerce platform, the finance aspects associated with accounting for things formally and the warehousing and distribution aspects for how the magic happens. 

Naturally the real world is complex, and every situation is different. So below is a high level summary of how the different aspects are connected together. 

1. When a Customer clicks that magic “Buy” button on an ecommerce store and completes the Checkout process…..
2. This naturally includes a few key elements to the order, some of which you see as a Customer, others which are triggered after the fact….
3. The three obvious ones are the Invoice, the Shipping Address and the Billing Address, so let’s dive into some of those things in a little more detail and their relationship with the Customer as some of the syntax on the diagram below may not be familiar if you haven’t see these before…..
4. Firstly, when it comes to Data Modelling, there are generally 4x types of Relationships between Objects. An Object in simple terms is just something you talk about, it can be anything and there are often no right or wrong approaches, there just tend to be best practices which will become apparent the more you get involved with these things. The relationships are, One to One (—), One to Many (–<), Many to One (>–) and Many to Many (>–<)
5. So here a Customer can have Many Invoices, because you may want to purchase things again and again like you do with Amazon, which makes perfect sense
6. Then there is a Single Customer Billing Address, which may be the same or different than the Shipping Address for where the Products are being sent. The reason why there is always a Billing Address and Shipping Address as two separate entities is primarily for more complex situations beyond you personally buying a book from Amazon. In a business context, let’s say you have two offices, you would have your Billing Address likely as the primary location but you may want to ship some office supplies to the other office, which makes sense. There is also a complex Tax calculations that are based around the Billing Address, but that’s a bit out of scope of this post. 
7. So let’s jump onto the next critical step, the Order. The Order is very similar to the Invoice with the critical difference that the Invoice is designed to financially account for the transaction whereas the Order is designed for actually processing the order throughout the business to get the Products shipped out. Both have their respective Line Items which include Quantities which is designed to handle the situation whereby the Customer has ordered multiple different Products on the same purchase. 
8. And the rest is fairly self explanatory. The Products tend to belong to a Product Category (i.e. Books or Clothing etc.), and they are physically stored in some kind of Warehouse which is managed in complex environment through Inventory Management Systems. 
9. And finally the Products get shipped out be your favourite Shipping Provider who comes knocking on your door to deliver the goods. 
10. And that’s about it!

As mentioned earlier, the reality is significantly more complex under the hood, but this hopefully gives you an idea for how the different components fit together. The conceptual data models are the foundation to understanding complexity at scale. 

And what’s even better, you can get started creating your own today for whatever problem you are working on. 

Ecommerce Data Model Including Finance and Warehouse and Shipping