DDD台湾社区活动纪实第二弹

Kim Kao ( 高翊凱 )，目前任職於Amazon Web Services (AWS) 擔任解決方案架構師，致力於幫助客戶與對雲端服務有興趣的夥伴一起領略雲端服務的價值。在加入AWS之前是個軟體架構師，醉心於各種軟體方法的學習與實踐，尤其對領域驅動設計的思維特別感到興趣，目前在台灣發起了Domain Driven Design Taiwan Community，各種線上線下社群活動陸續開展中，歡迎你一起加入我們的行列，一起交流軟件設計的甘苦談。

在第一次举办meetup后，社群的志工团队开始逐渐招募成型，我们不断的在想著怎麽样可以让这样刚萌生的热可以延续下去，从1/26到3月份我关注到一个状况，每天都有不断收到的加入社群的请求，这是一件鼓舞社群志工团队的很重要的讯息，有人有兴趣来探索与了解，都是将我们推进的动力。

不过，有一个不容易解决的困扰那就是社群成员的组成的多元性，不知道是大家谦虚还是什麽原因，加入社群的提问问题之一是 “您对DDD的认识程度，请自评1~5”

为了想要更全面的关注社群伙伴，在本次的议程安排上真的是想破头了!

这次的议程包括了有：

• DDD with Clean Architecture, Arthur Chang
  

• 团队协作实战DDD, Jed Lin

• Essential capabilities behind Microservices, Kim Kao

以下我分别对这些议程做些我在仅有的参与过程中的回顾，碍于篇幅关係若你对这些主题有兴趣可以直接点阅简报，并且找到DDD社群与大家交流。

作为社群发起人之一的Arthur 为了要更添加主题的讨论层次，也尽量与当天讲者们的话题不要完全重複，把主题定为成揉合Clean Architecture的DDD的探讨，虽然在开场时他特别说到 :

但就整体的内容广度来说，我相信之后要安排(X)推坑(O)进行各种环节的系列深入话题交流应该也是没问题的。

这次在Arthur的议程中谈到了架构因子(架构因子来自于温昱的一本书:一线架构师)，唤醒你对做架构设计时可能需要去思考的诸多变因与影响来源，尤其在组织结构上的影响也多是如此，另外一个很重要的思考点是： 维度。

对于系统来说影响到一个软件架构的维度有4:

• Component 的扩充考量
  

• Layer 的扩充考量

• 多个系统之间协作的扩充考量

• 基于时间变化的挑战

时间，是一个驱动业务变革的主因，也同时经常因为如此导致不可逆的架构转变，甚至产生了业务项目重点的”轴变”。某些企业可能会在经营主要业务之馀开始去尝试其他的更多市场机会，一但在某个试点的项目中开始获得成效而最终发现这个新项目成了这企业的救命符时，这时候对此企业来说他的核心关注价值重点，已经发生了商业价值上的轴转，这时候果断的企业主很可能就会思考把重点领域关注做出翻转，进而获取更重要的价值与经营。

另外要特别感谢 Jed Lin花了很多时间的准备，早在社群成立非常早的初期，我就不断的打扰(O)邀请(X)他，务必请他能尽量抽出时间与大家分享在过去的工作中的实际开发经验，而事实上 Jed 本人也表示 :

在这个主题当中，Jed把软体设计本身看待成 解决业务问题与技术问题为起点 ，鼓励大家更多的关注在业务本身，同时在面对领域模型捕捉的部分，揉入了 Impact Map以及 User story mapping的面向做引导，这手法你我不陌生，但是你可能过去没有特别去思考过这方式，而今你可以试著想想或体验她。

Eric Evans在当初撰写与推广DDD的时候其实在运作手法上并没有特别的陈述有哪些实作可行的方式，而现在你可去尝试你任何可能可以达到团队共创以及使用 统一语言 来达到交流与共同理解的方法，那麽它就是一个高效有意义的方法。

有了建模基础之后，我们经常在过去的开发经验中被要求提交系统分析规格书，或者系统设计规格书，尤其如果你是跟我一样做了很多年的SI背景经验的人，你很能理解撰写这些 “一次性文件”代表的浪费与痛苦。