Logical Separation in the Hexagonal Architecture

Have you ever lied to your stakeholders? I must confess that I did once (unintentionally)... I drew a very nice picture of boxes and arrows and I presented it to them as the "logical view" of the architecture of the software product they were in charge of. However, those logical boxes, which were supposed to be groups of classes with a specific purpose, were not represented in code. Source code was a real mess, basically just spaghetti code. There were dependencies everywhere without any defined rules or without any architectural rule. There was a clear gap between my picture and the source code.

If you have read my previous post, Coding your Architecture Structure, you know that one of the structures to architect a software system is created using syntactical constructions. Usually those constructions are packages, namespaces, or modules. So, with this idea we create an application using the Hexagonal Architecture Style, where each logical group of classes that this style suggests is represented as a package in the picture below.

Data Boundaries Are the Root Cause of Maintenance Problems

Many designs and patterns old and new, like the Layered ArchitectureClean ArchitectureHexagonal Architecture, DCI, and others introduce data-oriented boundaries inside the application.

Data-oriented boundaries are interfaces between architectural parts that primarily consist of data in the form of "properties" that can be freely accessed either directly, through getter methods, reflection, or some other technical means.