Joseph Ferris

I am the co-owner and Principal Architect at Ferris Consulting, LLC. Currently, I am involved in a long-term engagement with my primary client. When I am not working, I enjoy reading about enterprise architecture and trying to distill those practices into various hobby-related coding projects.

Just to provide a brief update, I am expecting our next article to be published on either Tuesday and Wednesday. There, we will be introducing Architectural Unit Tests to help us enforce some of the more abstract requirements of our project. As it currently stands, I am uncertain if it will be a a multiple-part article or just one larger article. Now that I have prepared the code samples and have actually started writing, I have realized that there is more ground to cover than I had expected. Those who already have read the previous article, Defining Entities, Value Objects, and Aggregate Roots, may notice that there has been a slight change. While I had planned on covering enforcement through FxCop, the technical overhead to actually get the FxCop SDK to play nice was distracting from the goal. No worries, though, because the current approach will be more focused on the goal and not the technology. Hopefully, you find it will be worth the slight delay that the course correction has created.

Defining Entities, Value Objects, and Aggregate Roots

One of the most important considerations that we face in implementing a project which is backed by Domain-Driven design is that we must be able to express its Strategic Patterns in both code and architectural constraints.  If we do not define that framework up front, we are not setting the team up for success.  Even within that framework, there is a central set of concepts that are required ahead of others, as they will both be built upon and extended, as we introduce other concepts.  To that end, we will begin by taking a look at Entities, Value Objects, and Aggregate Roots.

Continue Reading

Structuring Projects for Domain-Driven Solutions

Project organization is a topic that many developers speed through and eventually come to fight through as a project matures. The subject matter may seem mundane, but considering all of the other day-to-day responsibilities which consume time and impact deadlines, a poorly structured project is something that can have a minimized impact with just a small amount of planning. When implementing Domain-Driven Design, the organization of a solution into a series of specifically-purposed projects does not just reduce unforeseen development costs, it helps to enforce the required separation of concepts and responsibilities.

Continue Reading

The Trouble with the Always-Valid Entity

There is no better way than to kick off a new blog with a bit of controversy. When it comes to Domain-Driven Design, there is no greater divergence in interpretation and opinion than what is meant by the "always-valid entity" and how it is actually implemented. Even amongst the consummate experts, how validity and validation are put into practice can vary greatly. Over the years, I have slowly drifted between the different camps, finding that one interpretation better fit one project than the next. However, I now find myself wondering if the solution is not really as black-and-white as it has been presented.

Continue Reading