<blockquote>
The layer most developers rush through is the one that determines whether your codebase survives contact with the real world.
</blockquote>
<hr>
<h2>Day 3 of building SGAcademy in public</h2>
Yesterday I talked about naming your variables properly. Today I set up the domain layer for SGAcademy — the school management system I’m building in public.
And I want to walk you through exactly what I did, what decisions I made, and why.
Because the domain layer is where most junior devs go wrong. Not because they’re not smart enough. Because no one shows them what it’s actually supposed to do.
<hr>
<h2>What the domain layer actually is</h2>
If you’re using Clean Architecture (which SGAcademy uses), your codebase is split into layers:
<ul>
<li>Domain — your business logic, entities, and rules. No dependencies on anything external.</li>
<li>Application — use cases that orchestrate domain logic.</li>
<li>Infrastructure — databases, APIs, file systems.</li>
<li>Presentation — your controllers, your UI.</li>
</ul>
The domain layer sits at the center. It knows nothing about Entity Framework, nothing about HTTP, nothing about SQL Server. It just knows what your business is.
For SGAcademy, the business is running a school. So the domain layer knows about students, classes, enrollments, attendance, sections, and fees. It does not know about REST or JSON or database tables.
That separation is the whole point.
<hr>
<h2>The three things that live in your domain layer</h2>
<h3>1. Entities</h3>
An entity is an object with a unique identity that persists over time. In SGAcademy:
<pre><code class="language-csharp">public class Student
{
 public Guid Id { get; private set; }
 public string FullName { get; private set; }
 public string RegistrationNumber { get; private set; }
 public DateOnly DateOfBirth { get; private set; }
 public EnrollmentStatus Status { get; private set; }

 private Student() { } // EF Core requirement

 public static Student Create(string fullName, string registrationNumber, DateOnly dateOfBirth)
 {
 if (string.IsNullOrWhiteSpace(fullName))
 throw new DomainException(&quot;Student name cannot be empty.&quot;);

 return new Student
 {
 Id = Guid.NewGuid(),
 FullName = fullName,
 RegistrationNumber = registrationNumber,
 DateOfBirth = dateOfBirth,
 Status = EnrollmentStatus.Active
 };
 }
}
</code></pre>
Notice what this class does not have: no <code>[Required]</code> attributes, no <code>DbSet</code>, no HTTP references. Pure business object.
Also notice: the setters are <code>private</code>. You cannot change <code>FullName</code> from outside the class. You have to go through a method. That’s intentional — it means every state change goes through code you control.
<h3>2. Value Objects</h3>
A value object has no identity. It’s defined entirely by its values. Two value objects with the same values are equal.
In SGAcademy, a <code>FeeAmount</code> is a value object:
<pre><code class="language-csharp">public record FeeAmount
{
 public decimal Amount { get; }
 public string Currency { get; }

 public FeeAmount(decimal amount, string currency)
 {
 if (amount &lt; 0)
 throw new DomainException(&quot;Fee amount cannot be negative.&quot;);

 Amount = amount;
 Currency = currency;
 }

 public FeeAmount Add(FeeAmount other)
 {
 if (Currency != other.Currency)
 throw new DomainException(&quot;Cannot add fees in different currencies.&quot;);

 return new FeeAmount(Amount + other.Amount, Currency);
 }
}
</code></pre>
Using <code>record</code> in C# gives you value equality out of the box. Two <code>FeeAmount(5000, &quot;PKR&quot;)</code> instances are equal. That’s the right behavior.
<h3>3. Domain Events</h3>
Something important happened in your system. You want other parts of the system to react — but you don’t want your <code>Student</code> entity to know about email services or audit logs.
Domain events solve this:
<pre><code class="language-csharp">public record StudentEnrolledEvent(Guid StudentId, Guid ClassId, DateTime EnrolledAt)
 : IDomainEvent;
</code></pre>
The entity raises the event. The application layer handles it. Clean separation. No coupling.
<hr>
<h2>The rule that makes or breaks your domain layer</h2>
Business rules live in the domain. Not in the controller. Not in the service. In the domain.
Here’s what that looks like in practice.
Wrong:
<pre><code class="language-csharp">// In your controller
if (student.Status == EnrollmentStatus.Graduated)
 return BadRequest(&quot;Cannot enroll a graduated student.&quot;);

await _studentService.Enroll(student, classId);
</code></pre>
Right:
<pre><code class="language-csharp">// In your Student entity
public void EnrollInClass(Guid classId)
{
 if (Status == EnrollmentStatus.Graduated)
 throw new DomainException(&quot;A graduated student cannot be re-enrolled.&quot;);

 AddDomainEvent(new StudentEnrolledEvent(Id, classId, DateTime.UtcNow));
 Status = EnrollmentStatus.Active;
}
</code></pre>
The difference: in the first version, that validation can be skipped. If another controller, another service, or another developer calls <code>_studentService.Enroll</code> without the check — the rule is broken.
In the second version, the rule is inside the entity. It is impossible to enroll a graduated student without hitting that check. The domain enforces its own invariants.
That’s what invariant protection means. That’s why it matters.
<hr>
<h2>What I actually built today for SGAcademy</h2>
Here’s the domain structure I set up:
<pre><code>SGAcademy.Domain/
├── Students/
│ ├── Student.cs
│ ├── EnrollmentStatus.cs
│ └── Events/
│ ├── StudentEnrolledEvent.cs
│ └── StudentSuspendedEvent.cs
├── Classes/
│ └── Class.cs
├── Attendance/
│ ├── AttendanceRecord.cs
│ └── AttendanceStatus.cs
├── Fees/
│ ├── FeeRecord.cs
│ └── FeeAmount.cs
├── Common/
│ ├── Entity.cs (base class with Id and domain events)
│ ├── IDomainEvent.cs
│ └── DomainException.cs
</code></pre>
Every entity inherits from <code>Entity&lt;T&gt;</code> which gives it an <code>Id</code> and a list of domain events to raise. Every rule that the business cares about lives inside these files.
No database config. No HTTP dependencies. No EF Core attributes (except the private constructor for EF’s reflection).
Just the business.
<hr>
<h2>The mistake I see most often</h2>
Anemic domain models.
An anemic domain model is when your entities are just bags of properties with no behavior:
<pre><code class="language-csharp">// Anemic — no behavior, just data
public class Student
{
 public Guid Id { get; set; }
 public string FullName { get; set; }
 public EnrollmentStatus Status { get; set; }
}
</code></pre>
All the logic ends up in service classes. The service classes grow to hundreds of lines. Rules get duplicated. Rules get missed. The codebase becomes fragile.
If your entity has public setters on everything and methods that do nothing, you have an anemic model. The fix is to move behavior into the entity — make it responsible for its own state.
<hr>
<h2>One principle to take away</h2>
Your domain layer is the translation of your business into code.
If a business rule changes, the domain changes. If the database changes, the domain does not. If the API changes, the domain does not.
That stability is what makes the rest of your codebase maintainable. Rush the domain and you’ll feel the pain in every layer above it.
Take your time here. Name things precisely. Enforce your invariants. Raise events for things that matter.
<hr>
<h2>Tomorrow</h2>
Day 4: Setting up the Application layer — how use cases are structured, how services are organized, and what actually connects the domain to your API.
<hr>
Learn | Build | Ship — BuildWithRafique <code>&lt;R/&gt;</code>
#buildinpublic #dotnet #cleanarchitecture #devtips #learntocode #webdev #sgacademy

Your domain layer is the most important thing you'll write.