微服务架构可以让业务架构的开发与运维管理变得简单高效,提高系统的可用性。与此同时... 展开 >




超过15年的软件开发和设计经验,一直致力于系统复杂性应对之道。对DDD的战略设计和战术设计有丰富的实战经验,在探索将战术设计落地为面向对象友好的技术实现,有丰富收获。
微服务架构可以让业务架构的开发与运维管理变得简单高效,提高系统的可用性。与此同时也会带来很多开发与运维上的负担。而使用DDD(领域驱动设计)的思想去指导微服务的实践则成为比较好的方案。
零售通业务在快速奔跑过程中,因为应用架构的缺失,领域模型的不合理,导致系统腐化,维护成本很高。我们所采用的解决方案是,重新划分领域边界,提炼出业务的核心要素进行领域建模,并采用新的应用架构分层,创新式的选用共享内核组件和防腐层相结合的方式,解决边界上下文问题,使得商品域在读写分离的同时,又能以组件的形式共享内核。
此次演讲,我会结合零售商品平台案例,讲讲如何使用应用架构配合DDD落地,以及处理微服务带来的界限上下文问题经验。
演讲提纲:
听众受益点:
通常,可以将 DDD 的设计分为 "战略设计/战术设计/技术实现"三个阶段。在这三个阶段里,开发者的参与的程度是递增的。其中,战略设计阶段,是需要众多关键角色集中投入的协作设计过程,其产出结果的质量主要取决于业务专家等角色的知识、经验和能力,以及他们的参与程度和对 DDD 战略设计的思想和工具的掌握程度。而“战术设计阶段”是需要开发者深度参与的,最后的“技术实现阶段”则要完全由开发者来掌控。时至今日,用微服务架构来作为 DDD 的技术实现已经是最合适的选项了。
本次面向那些对 DDD 感兴趣的开发者,分享一些如何做“战术设计”以及用微服务做“技术实现”的经验和最佳实践。
演讲提纲:
听众收益点:
每个公司都希望研发的系统具备高扩展性,以便做产品和业务迭代时,成本降到最低,效率提到最高;当下流行的微服务架构、中台架构的目标都是在不同层面去解决扩展性的问题,然而无论采用什么架构思想,要提高扩展性,都需要直面模型设计的问题;领域驱动是当下为数不多提供了模型设计框架的一个方法论,能够帮助解决一部分设计的问题,但它也不是万金油,我们需要在正确的时机和场景下使用这个方法论,才能事半功倍。
中台化的建设路径上,主要分为烟囱化、服务化、平台化、中台化四个阶段,领域驱动主要在服务化的中后期和平台化阶段发挥作用,主要贡献是提供了顶层设计框架和常见问题的横向管控手段,在使用领域驱动过程中,我们也结合业务现状,补充了一些方法,配合领域驱动一起使用,取得了较好的效果。
实施效果也达到了预期,服务/平台边界更加清晰,维持了一个较好的领域抽象土壤,业务的 MVP 试错成本不断降低。
演讲提纲:
听众受益点:
Eric Evans《领域驱动设计》一书中就提到,领域模型绝不单单是领域专家头脑中的知识,而是对这类知识严格的组织且有选择的抽象。DDD思想并非适用所有的业务范围,它能解决的问题也比较有限。落地DDD同时也需要全员DDD意识培训,在项目中要不断的迭代,合理的规划/跨越边界等等。本次分享就以物流系统为例来讲讲DDD落地有哪些要点,以及如何在业务发挥最大价值。
演讲提纲:
听众收益点:



微信咨询

电话咨询
微信联系我们
