Domain Modeling

In researching for how to model a rather complex project for a course (ISYS 350 Building Business Applications).  I came across something quite by accident when pursuing the book titled Pro ASP.NET MVC Framework by Steven Sanderson.  He introduced Domain Modeling.

From what I discerned, I noted the following:

There are these components: entities, value objects, and aggregates.

The entity has an ongoing identity throughout its life time and has a unique (primary) key, while value objects are defined purely by value of attributes, are logically immutable, and have no key.

An aggregate is an arrangement of entities into a group that share some related function.  An aggregate has a root entity that can be related to entities outside of the aggregate.

What I was thinking was that this is a good model to design business applications and it can provide a common language for both engineers and business professionals, much in the same way E-R (Entity-Relationship) modeling works for relational databases and SQL. 

These types of modeling methodologies can help align technology pursuits to the business needs, something that is perfectly align to roles of business analysts, an area of my interest lately.

The author also mentions Domain Driven Design (DDD) who he credits to another author, Eric Evans.  Eric Evans published a book titled Domain-driven design: tackling complexity in the heart of software.  At some point, I would like to thumb through this book...