Kirk Borne posted to Twitter:
Great analogy by @wcukierski at #GEOINT2015 on #DataScience Domain Modeling > bulldozers: toy model versus the real thing.
Does your tool adapt to the data? (The real bulldozer above.)
Or, do you adapt your data to the tool? (The toy bulldozer above.)
No, I’m not going there. That is like a “the best editor” flame war. You have to decide that question for yourself and your project.
Good luck!
Functional and Reactive Domain Modeling by Debasish Ghosh.
From the post:
Manning has launched the MEAP of my upcoming book on Domain Modeling.
The first time I was formally introduced to the topic was way back when I played around with Erik Evans’ awesome text on the subject of Domain Driven Design. In the book he discusses various object lifecycle patterns like the Factory, Aggregate or Repository that help separation of concerns when you are implementing the various interactions between the elements of the domain model. Entities are artifacts with identities, value objects are pure values while services model the coarse level use cases of the model components.
…
In Functional and Reactive Domain Modeling I look at the problem with a different lens. The primary focus of the book is to encourage building domain models using the principles of functional programming. It’s a completely orthogonal approach than OO and focuses on verbs first (as opposed to nouns first in OO), algebra first (as opposed to objects in OO), function composition first (as opposed to object composition in OO), lightweight objects as ADTs (instead of rich class models).
The book starts with the basics of functional programming principles and discusses the virtues of purity and the advantages of keeping side-effects decoupled from the core business logic. The book uses Scala as the programming language and does an extensive discussion on why the OO and functional features of Scala are a perfect fit for modelling complex domains. Chapter 3 starts the core subject of functional domain modeling with real world examples illustrating how we can make good use of patterns like smart constructors, monads and monoids in implementing your domain model. The main virtue that these patterns bring to your model is genericity – they help you extract generic algebra from domain specific logic into parametric functions which are far more reusable and less error prone. Chapter 4 focuses on advanced usages like typeclass based design and patterns like monad transformers, kleislis and other forms of compositional idioms of functional programming. One of the primary focus of the book is an emphasis on algebraic API design and to develop an appreciation towards ability to reason about your model.
…
An easy choice for your holiday wish list! Being a MEAP, it will continue to be “new” for quite some time.
Enjoy!
From the webpage:
What is Qi4j™?
The short answer is that Qi4j™ is a framework for domain centric application development, including evolved concepts from AOP, DI and DDD.
Qi4j™ is an implementation of Composite Oriented Programming, using the standard Java 5 platform, without the use of any pre-processors or new language elements. Everything you know from Java 5 still applies and you can leverage both your experience and toolkits to become more productive with Composite Oriented Programming today.
Moreover, Qi4j™ enables Composite Oriented Programming on the Java platform, including both Java and Scala as primary languages as well as many of the plethora of languages running on the JVM as bridged languages.
Introducing Qi4j™
Qi4j™ is pronounced “chee for jay”. This website is out of scope to explain the many facets and history of Qi, so we refer the interested to read the lengthy article at Wikipedia. For us, Qi is the force/energy within the body, in this case the Java platform. Something that makes Java so much better, if it is found and channeled into a greater good.
We strongly recommend the background article found in the introduction.
Covering Qi4j in part because Emil Eifrem covers it in his “kicking ass” slides on Neo4j.
But also because I like domain oriented design.
Software should fit a domain and not have domains tormented to fit software.
That does create problems with what to standardize and what to enable to be unique. Not everyone can afford one-off software.
My suggestion would be to standardize the interchange of data to enable competition between unique capabilities of software, so long as it write back to a standard format.
From entries at the website it appears that Qi4j is emerging from a period of dormancy. Now would be a good time to contribute to the project.
Large-scale Pure OO at the Irish Government by Richard Pawson.
From the website:
Richard Pawson discusses a case study of a large pure OO project for the Irish government, presenting the challenges met, the reason for choosing pure OO, and lessons learned implementing it.
This is an important presentation mostly because of Pawson’s reliance on Domain Driven Design (Evans) and the benefits that were derived from that approach. I think you will find a lot of synergy with extracting from users the “facts” about their domains. Highly entertaining presentation.
Pawson’s “naked object” approach has both Java and .Net implementations:
Naked Objects – .Net at Codeplex
Apache Isis – Java at Apache Incubator
Perhaps not quite right for web-based or casual users, but for power-users of topic maps, this might have some promise. Thoughts?
Pawson talks about reuse of naked objects. How would you compose (impose?) a subject identifier for a “naked object?”
Powered by WordPress
