Modularity and Domain Driven Design; a killer combination?
17 likes5,839 views
The document discusses the integration of modularity with domain-driven design to enhance software architecture by improving customer satisfaction through predictable change costs and functional modularization. It highlights the advantages of independent module migration, internal database schema management, and the complexities of cross-domain database transactions and search functionalities. Additionally, it addresses challenges related to deployment and migration while suggesting leveraging technologies like Liquibase and Elasticsearch for better operational efficiency.
![$ curl -XPOST localhost:9200/vehicle/_search?pretty -d
‘{"query":{"match":{"make":"BMW"}}}'
{
"took" : 3,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"failed" : 0
},
"hits" : {
"total" : 2,
"max_score" : 0.30685282,
"hits" : [ {
"_index" : "vehicle",
"_type" : "external",
"_id" : "1",
"_score" : 0.30685282, "_source" : {"make": "BMW", "VIN": "30203232012102"}
}, {
"_index" : "vehicle",
"_type" : "external",
"_id" : "2",
"_score" : 0.30685282, "_source" : {"make": "BMW", "VIN": "30203232012112"}
} ]}}
!
Querying an index](https://image.slidesharecdn.com/modularityddd-140616042510-phpapp01/85/Modularity-and-Domain-Driven-Design-a-killer-combination-25-320.jpg)
Modularity and Domain Driven Design; a killer combination?
- 1. MODULARITY AND DOMAIN DRIVEN DESIGN a killer combination? Tom De Wolf Architect tom.dewolf@aca-it.be @tomdw Stijn Van den Enden CTO stijn.vandenenden@aca-it.be @stieno www.aca-it.be
- 2. initial development maintenance phase Software Design Customer Satisfaction Separation of Concerns Low coupling High Cohesion B AB A • Change A impacts all modules = costly • Change B requires split of module = costly • Change A only impacts other module if api change • Change B limited to module Encapsulate Source of Change Predictable Cost of Change Constant change Business Driven Aim for 1-on-1 mapping from business changes onto software constructs Source of Change = Business Functional Modularisation
- 3. Vehicle Option Make Warranty Model Transport Location Domain Driven Design Without modularity BusinessPartner Address Contact consumer supplier transports owner from to
- 4. Vehicle Option Make Warranty Owner Model Transported Item Transport Transport Supplier Transport Consumer Vehicle Context Transport Context Domain Driven Design Modularity with Bounded Contexts BusinessPartner AddressContact Business Partner Context Location from to
- 5. transport vehicle MODULAR DATABASE SCHEMA • cross domain database structures not allowed • queries cannot cross domain boundaries NO foreign key business partner UUID MAKE MODEL OWNER_ID djdfjfdkjdk221 Ford C-Max BE1234567 TRANSPORTED_ITEM_ID FROM CONSUMER_ID djdfjfdkjdk221 454 BE1234567 LOCATION_ID ADDRESS 454 Sunstreet 23 foreign key VAT_NUMBER NAME BE1234567 Company A
- 6. BENEFITS … • Domain modules can migrate independently to next version! • Database schema is internal to the domain bundle, i.e. NOT part of the API! • Persistence and/or database technology can differ between modules in one system!
- 7. Mmodular database migration cross domain transactions Tx Scross domain search and reporting C H A L L E N G E S
- 9. M Dev Machine 1 MIGRATION CHALLENGE Dev Machine 2 Continuous Integration Test environment Acceptance environment Production environment Version 1.0.0 Version 1.0.1 Version 1.0.2 Version ? Version ? Version ? environment x Module 1 Module 2 Module 3 Version 1.0.0 Version 3.0.0 Version 2.0.2 Manually track which scripts have run on which environment for which module ?
- 10. M LIQUIBASE DATABASECHANGELOG table to track executed changesets for each environment In versioned source code XML based DSL for changeSets www.liquibase.org
- 11. M MODULAR LIQUIBASE transportvehicle business partner deployment 1 deployment 2 deployment 3 Migrate modules separately Migrate @deploy of module migrate to initial version migrate to initial version migrate to initial version no db changes, no migration migrate to version 2 migrate to version 2 migrate to version 3
- 12. M THE EXTENDER PATTERN bundle A bundle B bundle C bundle D extender bundle Extension Pattern ?! no match /OSGI-INF/liquibase/db.changelog-master.xml osgi-liquibase-extender framework dependency Liquibase change sets domain A change sets domain B change sets domain C • Only extender depends on Liquibase framework • Update of single bundle triggers Liquibase update • New Liquibase process for each matching bundle
- 14. JTA OR NOT? • No persistence layer — direct jdbc/sql access — 1 datasource • Multiple datasources • Different types of persistence layers (JPA, NoSQL, …) • JPA persistence layer in each domain bundle • instead of one big persistence unit • even on 1 datasource T 1 transaction spanning multiple modular domains JTA not needed JTA required x
- 15. javax.transaction.TransactionManager transaction provider e.g. atomikos MODULAR PERSISTENCE T osgi-datasource XA enabled vehicle-domaintransport-domain javax.sql.DataSource persistence context persistence context commit x
- 17. Scross domain search SEARCH the tale of the evil joins
- 19. A. Search encapsulated in a separate module leveraging the functionality of other domain modules search- module domainA domainB x x Repository Repository Stop • requires specific implementation for every search • complexity increases with number of modules • inability to leverage power of the datastore SearchAPI
- 20. domainA B. Search is using a separate query model search- module domainB SearchAPI EventProvider Update Events Update
- 22. $ curl -XPUT ‘localhost:9200/vehicle/external/1’ -d ‘{ “make”: “BMW”, “VIN”: “30203232012102” }’ index document_type id Index a document
- 23. $ curl -XPOST ‘localhost:9200/vehicle/external/1/ _update’ -d ‘{ “doc”: {“make”: “Alpina”} }’ Update a document index document_type id
- 24. $ curl -XPOST localhost:9200/vehicle/_search?pretty -d ‘{"query":{"match":{"make":"BMW"}}}' index Querying an index
- 25. $ curl -XPOST localhost:9200/vehicle/_search?pretty -d ‘{"query":{"match":{"make":"BMW"}}}' { "took" : 3, "timed_out" : false, "_shards" : { "total" : 5, "successful" : 5, "failed" : 0 }, "hits" : { "total" : 2, "max_score" : 0.30685282, "hits" : [ { "_index" : "vehicle", "_type" : "external", "_id" : "1", "_score" : 0.30685282, "_source" : {"make": "BMW", "VIN": "30203232012102"} }, { "_index" : "vehicle", "_type" : "external", "_id" : "2", "_score" : 0.30685282, "_source" : {"make": "BMW", "VIN": "30203232012112"} } ]}} ! Querying an index
- 26. • Distributed (shards/replicas) • Advanced Quering (lucene/geo/ aggregation) • Facets (terms/ranges/histogram) • API (HTTP/Java/JavaTesting) • … {
- 28. 1Populate the index package be.vabfs.search.api; ! public interface SearchIndexService { void update(Object entityToUpdate); void delete(Object entityToRemove); ! void populate(); ! void clear(); ! } search SearchIndexService domainB Entity EntityListener @PrePersist @PostUpdate @PostRemove
- 29. 1Populate the index search SearchIndexService update(entity) Synchronise onTransaction Track updated entities A Map entities to searchData B Bulk update search index C
- 30. 1Populate the index Map entities to searchData B package be.vabfs.search.api.data; ! import java.util.List; ! public interface SearchDataProvider { ! Class<? extends Object> getEntityClass(); List<SearchData> index(Object entity); ! } domainB Entity SearchData
- 31. 1Populate the index Map entities to searchData B SearchDataProvider domainB Entity SearchData
- 32. 1Populate the index A search SearchIndexService update(entity) Synchronise onTransaction Track updated entities Bulk update search index C Map entities to searchData B SearchDataProvider domainB A
- 35. 2Enhancing Search search SearchService package be.vabfs.search.api; ! import … ! public interface SearchService { … ! SearchResults query(String query, int start, int rows, String sort, String sortOrder, String documentType); List<String> options(String field, String... documentTypes); List<SearchCriterion> availableCriteria( String... criteriaCategories); }
- 36. 2Enhancing Search package be.vabfs.search.api.criteria; ! import java.util.List; ! public interface SearchCriteriaProvider { String getProviderCategory(); List<SearchCriterion> getAvailableCriteria(); } package be.vabfs.search.api.criteria; ! public interface SearchCriterion { ! String getName(); String getKey(); String getUnitName(); SearchCriterionType getType(); SearchCriterionQueryType getQueryType(); String getDocumentType(); ! } "vehicle.mileage" "mileage" SearchCriterionType.NUMBER SearchCriterionQueryType.RANGE_NUMBER "SERVICE_ITEM" "km"
- 38. LESSONS LEARNED @deployment time migration = RISK • have CI build continuously migrate current production data Refactor wrong modularisation requires unwanted migration dependencies • reset/flatten migration change sets to restore modularisation Migration Cross domain search and reporting Effort to integrate search is limited • due to dynamic osgi service model Advanced search functionality is possible
- 39. WHAT IS NEXT? Multiple module versions active? Multiple schema versions active? • e.g. feature try-out to limited customer base Downgrade to older module version? • Previous schema with new data? Hot deploy while users are firing requests? • Migration still busy = failure Migration Cross domain search and reporting Domain Specific Query Language ! Exploiting elastic search capabilities beyond search, e.g. reporting
- 40. M Modular migration Liquibase extender @ DeployT Cross domain transactions Distributed JTA transactionsx S Cross domain search Elasticsearch view Functionally not limited by domain module boundaries to answer business questions Non-functionally future-proof platform with impact of change contained in loosely coupled domain modules
- 41. Tom De Wolf Architect tom.dewolf@aca-it.be @tomdw Stijn Van den Enden CTO stijn.vandenenden@aca-it.be @stieno www.aca-it.be