souther

What Souther expresses

Souther is a small JVM language for describing business data, value constraints, and state transitions, then generating types and behaviors that Java can use. The README says you write business rules with data and behavior. An invariant makes value constraints explicit, while behaviors implemented in Java make dependencies such as a database or a clock explicit. This keeps the domain model's boundary intact as it becomes an implementation. The README shows a flow. External input goes to a decoder, then to Souther data and behavior, then to an encoder and external output, with Java injecting dependencies at the Souther layer. Souther is intended to turn the specification DSL of Specification Model Driven Development, or SMDD, into an executable implementation model. It makes executable the constraints, validated construction, and outside world dependencies that the specification DSL leaves in comments. The README positions Souther as a way to lift a written specification into running code without losing the boundary between the domain and the infrastructure it touches, which is the usual risk when a model is translated by hand. The flow diagram in the README places Java at the dependency injection point, so the domain rules stay in Souther while the outside world, a database or a clock, is supplied from Java code.

A worked example

The README starts with an example that either moves a travel request into a Submitted state or rejects it. An Amount cannot be negative, and the behavior produces either Submitted or Rejected. The example defines a module named example.trip and imports a length function from String. It defines EmployeeId as a String with an invariant that length is greater than 0. It defines Amount as an Int with an invariant that the value is greater than or equal to 0. It defines DraftRequest as a record of applicant and plannedCost, Submitted as the draft plus a submittedAt string, and Rejected as a record with a reason string. A behavior named submit takes a request and a submittedAt string and returns Submitted or Rejected. Its implementation guards that plannedCost is less than or equal to 100000, otherwise it returns Rejected with the reason high_cost, and otherwise returns Submitted spreading the request fields and adding submittedAt. The README uses this to introduce Souther's central ideas. Data with invariants, behaviors with explicit construction, and Java injected dependencies that keep the boundary clear. The example's guard returning Rejected with a reason shows that business rules live in the behavior, and the invariant on Amount keeps negative values out at the data level before any behavior can run.

Design goals and licensing

The README says Souther makes executable the parts of a specification that are usually left as comments. Constraints, validated construction, and outside world dependencies. By writing data and behavior in Souther and implementing behaviors in Java, the dependency on a database or a clock becomes explicit rather than hidden. This keeps the domain model's boundary clear as the system grows. The project is released under the Eclipse Public License 2.0, and the primary language is Java according to the project metadata. The README links to Specification Model Driven Development as the inspiration and shows how Souther turns that DSL into an implementation model. The example with the travel request shows the practical shape of a Souther module. Data declarations with invariants, a behavior signature, and a Java backed implementation. The README does not describe a build or install command in the excerpt, but it presents Souther as a compiler or processor that generates Java usable artifacts from the data and behavior definitions, turning a written spec into code that the JVM can run. The Eclipse Public License 2.0 is named in the metadata, and the README ties Souther to Specification Model Driven Development, so the project's aim is to make a written spec run directly on the JVM.

Editorial conclusion

Souther is written in Java and is released under the Eclipse Public License 2.0. It is intended to turn the specification DSL of Specification Model Driven Development into an executable implementation model.