Domain Modeling: Creating Conceptual Models for Software

Introduction

What is Domain Modeling?

Domain modeling refers to the process of creating a conceptual representation of a specific problem domain within a certain context. It is a fundamental step in software engineering.

A Domain Model provides a simplified view of the domain that helps stakeholders communicate and understand business needs and processes. It serves as the foundation for developing the software system.

Domain modeling also applies to front-end development. All User Interfaces, actions, interactions, and presentations have a strong basis in domain modeling.

Domain modeling involves identifying key entities, attributes, relationships, and constraints within the problem domain that the software aims to address. Tying together these four components are actions.

In Software Engineering, domain modeling plays a major role. Sometimes this is done implicitly, while other times it is called schema design or database design. The specifications come out of this process.

Essentially, Domain Modeling is representing the real world in software systems.

For example, Flipkart modeled the domain of selling books online. Uber modeled the domain of taxi services. Clear Tax modeled the domain of taxes.

How did people who built software start?

The first step in building software is typically domain modeling. However, with enough software engineering knowledge and programming experience, one could take a different approach.

Many people prefer jumping straight into coding. At some point though, you need to represent the business or product domain in the software due to the importance of understanding the domain.

Domain modeling features heavily in many big tech interviews.

The main components of a domain model are:

- Entities (Things, Nouns)

All entities behave in a way that is related to each other. Entities are the things that exist in the system. In Software Literature entities are called nouns. Ex: Take Twitter for example, If we observe on Twitter, a tweet is an entity, the user is an entity.

Obvious and Non-Obvious(Counter-Intuitive) entities: Some of the obvious entities that could exist in domain models for retail, media streaming, and library systems.

• Retail:

  • Obvious Entities: Customer, Product, Order, Invoice, Cart, Item.
  • Non-Obvious Entities: Price Trend, Location.

• Streaming Services:

  • Obvious Entities: Movie, Song, Episode, Profile, Watch history, Genre.
  • Non-Obvious Entities: Homepage, Most Popular, Recommendation, Viewing Session.

• Library :

  • Obvious Entities: Book, Author, Edition, Magazine, Shelf, Genre.

- Attributes (Properties)

Attributes are also entities or things but they don't have existence on their own.

Ex: Take Twitter for example,

• A tweet is more than a text, it has a time stamp. So context time stamp bunch of other things make it a tweet. But the time stamp itself does not have any existence of its own. So it's an attribute of a tweet.

• A user can have multiple attributes like names, locations, preferences, and pronouns.

• Profile Picture could be an attribute or it could be an entity on its own.

• When a user posts a tweet. Sometimes upload a picture to it and add text to the picture. So all the text is a property of the picture of all of the images the user uploads. So it is also an attribute of tweets.

Obvious and Non-Obvious(Counter-Intuitive) Attributes :

• Obvious Attributes: Names, Emails, Birthdays.

• Non-Obvious Attributes: Address, Location.

- Relationships (1 to N, N to N, 1 to 1)

These describe how the entities are associated or related to each other.

There are three types of relationships:

• One-to-One (1:1) Relationship: This represents that an entity instance in one entity is related to a maximum of one instance in another entity 1:1 relationships allow unique identification of related entities.
  Ex: A user has one profile, A Person has one SSN, A user has one timeline, and A user has one account.

• One to Many(1:N) Relationship: This represents that an entity instance in one entity can be related to multiple instances in another entity. 1:N relationships allow the modeling of logical hierarchies.
  Ex: A user makes many tweets ,A tweet has many likes, A user
  follows many other users, A post has many comments, An author
  writes many books.

• Many to Many(M: N) Relationship: This represents that entity instances in each entity can be related to multiple instances in the other entity. M: N relationships require an associative entity to link them.

  Ex: A tweet has been tagged with many hashtags, a hashtag is
  associated with many tweets, a user is a member of many
  groups, a student enrolls in many courses, and a supplier
  provides many products.

Relationships have direction indicating traversal and access and Cardinality indicates how many instances can be related. Properly identifying and modeling relationships is crucial for an accurate domain model that reflects the real business or problem space being represented.

- Constraints (Rules, Restrictions)

Constraints in domain modeling define valid data values and business rules that apply to entities and relationships. Constraints are also known as Invariants. In the business world, it is also known as rules.

• Famous Constraints :

  • Username Uniqueness(Twitter/Facebook)
  • 280 Character limit(Twitter)
  • No name change on Facebook.
  • Geofences on Uber.
  • Return date must be after the start date. (Flight Tickets)
  • Tweet must belong to a User (Referential)
  • Video can only be 720p, 1080p, 1440p (Domain)
  • Unique Season Number and Episode Number (Key) Book must have a Name (Null)
  • Latitude must be between [-90, 90]
  • Not So Obvious Constraints :
  • No Sign Up Until you read the Terms and conditions.
  • Only regular voters count in the IMDb Top 250.
  • Can only unpause Subscription X days after Pausing.
  • Must Wait Y months to delete account on .
  • No “Back” button on Banking Websites.

Some constraints are enforced by logic, data types or databases.

- Actions (Verbs)

Actions are exactly what you would expect and what you would intuitively figure out of it. The key is to identify the domain actions. Actions represent the behaviors, functions or operations that can be performed by the entities in the domain model. Actions are central to software engineering. Actions are what you typically build in software.

Conclusion

Domain modeling is not exclusive to backend development; it plays a crucial role in frontend development too. By embracing domain modeling principles and techniques, front-end developers can create user-friendly, efficient, and maintainable interfaces that align with the problem domain. Whether you're building a personal project or contributing to a larger team, mastering domain modeling in the context of front-end development will undoubtedly enhance your skills and make you a more effective developer. Happy coding!